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The solar system on this month's cover represents the system software for the HP 9000 
Series 500 Computers. We first told you about the HP 9000 in our August 1983 issue, 
which was devoted to the advanced technology that makes the Series 500 possible. You 
may recall reading about the HP 9000's five VLSI (very large-scale integration) chips — among 
them a 32-bit, 450,000-transistor central processor chip — made by a high-tech integrated 
circuit process called NMOS III. To help manage the heat generated by all those densely 
packed circuits, a new kind of circuit board, called a finstrate, was developed. The finstrates 
in each HP 9000 Series 500 Computer are contained in a lunchpail-sized module that holds 
up to three central processors. These technological developments make it possible to put on an engineer's 
desk a computer that has more power than some mainframe computers — "mainframe" being the name applied 
only to the largest computers. The HP 9000 Model 520 is the desktop mainframe. Models 530 and 540 are, 
respectively, rack-mount and cabinet versions designed to serve multiple users. 

Although the lunchpail-sized module is the beginning, between it and that desktop mainframe is a great 
deal of development in both hardware and software. This month's issue covers the system software develop- 
ment. In May, we'll cover the hardware development, and in future issues, we'll carry articles on significant 
applications software packages. In this issue you can read about operating systems, languages, input/output, 
networking, and multiprocessor management. An unusual aspect of the HP 9000 Series 500 is that there are 
two levels of operating system. What the user sees is either an advanced version of the HP BASIC system 
or an HP version of Bell Laboratories' UNIX operating system. Underlying those systems is the Series 500's 
SUN operating system, whose name gave us the idea for our cover photo. The SUN concept proved invaluable 
in the development of the two user operating systems. 

-R. P. Dolan 

Editor. Richard P Dolan • Associate Editor. Kenneth A Shaw • An Director Photographer. Arvid A Danielson • Illustrators, Nancy S Vanderbloom, 
Susan E. Wright • Administrative Services. Typography. Anne S LoPresti. Susan E. Wright * European Production Supervisor. Henk Van Lammeren 

2 HEWLETT-PACKARD JOURNAL MARCH 1984 C Hewlett-Packard Company 1984 Pnnted in U.S.A. 

© Copr. 1949-1998 Hewlett-Packard Co. 



A New 32-Bit VLSI Computer Family: 
Part II— Software 

Based on HP's proprietary 32-bit VLSI NMOS-III technology, 
the HP 9000 Series 500 Computers use local area 
networking and HP-UX, HP's enhanced version of UNIX 1 " 
An advanced version of BASIC that uses run-time compiling 
is available on the Model 520 integrated workstation. 

by Michael V. Hetrick and Michael L. Kolesar 



IN 1981 HEWLETT-PACKARD described the develop- 
ment of a single-chip 32-bit processor' fabricated with 
a new VLSI process technology called NMOS III. 2 This 
new technology was also used to develop four other 32-bit 
chips that, coupled with the design of a special copper- 
cored circuit board called a finstrate, enable a powerful 
multiprocessor 32-bit computer system to be packaged 
within a module no larger than a loaf of bread. The design 
of the five chips, the module, and the finstrate. and the 
NMOS-III process were discussed in last August's issue. 

The compact module, called the Memory /Processor Mod- 
ule, forms the heart of a desktop engineering computer 
workstation, the HP 9000 Computer, introduced by HP in 
1983. Now known as the HP 9000 Model 520. it contains 
a 5 Winch flexible disc drive, has four I/O slots, and has a 
choice of either a color or monochromatic 13-inch CRT 
display. Depending on the choice of the twelve finstrates 
possible in the Memory/Processor Module, up to three 
CPUs, three I/O processors, or 2.5M bytes of RAM can be 
installed. Available options include an internal thermal 
printer and an internal lOM-byte hard disc memory. 

A sophisticated internal operating system, called SUN. 
was developed to coordinate this compact multiprocessor 



computer system. A high-performance interactive high- 
level language system is required to allow a user to take 
full advantage of the features included in the Model 520. 
An enhanced version of BASIC and a run-time compiling 
technique were developed. This version was designed as 
a superset of the BASIC used on earlier HP desktop comput- 
ers so that users could easily port existing software to the 
Model 520. 

In late 1983. the HP 9000 family of computers was de- 
fined to include some earlier 16-bit technical desktop com- 
puters, 3 now known as the Series 200, and alternative pack- 
ages for the Memory/Processor Module, which with the 
Model 520. form the Series 500. To simplify the porting of 
software developed by other companies to the HP 9000 
family, HP-UX. an enhanced version of UNIX", was de- 
veloped. LAN 9000 was developed to provide local area 
networking. 

Fig. 1 depicts all current HP 9000 models. The primary 
distinction between the Series 200 and Series 500 Comput- 
ers is in their microprocessor, or central processing unit 
(CPU), and the ensuing system design. All Series 200 mod- 
els are based on Motorola's 16/32-bit 68000 microprocessor, 
while all Series 500 models use HP's proprietary 32-bit 

UNIX Is a U S trademark ol Boll Laboratories 



HP 9000 Computers 



I 



Series 200 

• MC 68000 Microprocessor 

• 18-32-BM Architecture 



Series 500 

• HP's NMOS-III VLSI Chip Set 

• 32-Bit Architecture 





Model 220 

(HPteM) 




Fig. 1. The HP 9000 family of 
computers includes the Series 
200 and the Series 500 Comput- 
ers The Series 200 is based on 
the 16/32-bit 68000 micropro- 
cessor and the Series 500 is 
based on HP's proprietary 32-bit 
VLSI NMOS-III chip set The Series 
200 is lower in cost and the Series 
500 has higher performance Pro- 
grams developed in BASIC on the 
Series 200 can be ported to the 
Model 520 ol the Series 500 lor 
decreased computation time and 
other performance advantages. 



MARCH 1984 HEWLETT-PACKARD JOURNAI 3 



© Copr. 1949-1998 Hewlett-Packard Co. 



Contrasting Project Management 

The relative magnitudes of the BASIC and HP-UX projects 
created interesting and contrasting software management tech- 
niques. BASIC, being relatively small in code size by today's 
standards (less than one megabyte) was implemented entirely 
within HP's Fort Collins Systems Division (FSD). A development 
environment known as MODCAL. which ran on previous-gener- 
ation desktop computers, was an effective tool for code develop- 
ment. Since the project was executed by a few engineering 
groups in one department, coordination among the design team 
was extremely efficient. 

HP-UX development, on the other hand, was much larger m 
scope; it resulted in approximately 1 0 megabytes of system code. 
Features such as multiple languages, graphics, networking, and 
fundamental program development tools were required. HP en- 
tities outside of FSD had the expertise to contribute in some of 
these key areas. Thus, two California organizations — the Com- 
puter Language Laboratory (CLL) and the Engineering Produc- 
tivity Division (EPD) — along with the Colorado Networks Opera- 
tion (CNO) provided FSD with major software subsystems. CLL 
produced the FORTRAN and Pascal compilers, EPD developed 
HP's well-known two- and three-dimensional graphics libraries, 
and CNO provided most of the data communications and net- 
working software 

FSD ported the UNIX" commands and created the System III 
UNIX interface to the existing Series 500 operating system. FSD 
was also responsible for coordinating the entire software develop- 
ment and integrating all subsystems into a cohesive product. 

As the HP-UX asynchronous communications software be- 
came functional, it was used to transmit messages and internal 
software updates between divisions. FSD and CNO capitalized 
on high-speed local area network prototype hardware and soft- 
ware to update local systems electronically. 

Thus, many HP-UX software subsystems became key develop- 
ment tools even as they were being created. (The UNIX command 
set, C, FORTRAN, and Pascal compilers, and SCCS, the source 
code control system, are additional examples.) Their everyday 
use not only contributed to our development productivity, but 
also served as a prime example of how internal use of what will 
become a product improves the product's overall quality in a 
way that is not otherwise possible. 

•UNIX is a U.S. trademark of Bell LaDoraiones 

-Michael V. Hetrick 
-Michael L Kolesar 



CPU chip set mentioned earlier. Highly compatible system 
software spans the lower-cost Series 200 and higher-perfor- 
mance Series 500 workstations to provide a broad price/per- 
formance product family. BASIC is offered on all but the 
Model 530 and Model 540; HP-UX is offered on all but the 
Model 216 and Model 226. A standard HP Pascal develop- 
ment environment also appears on all Series 200 models. 

This issue discusses the development of the Series 500 
software systems with the exception of the multitasking, 
graphics, and I/O subsystems for Model 520 BASIC. They 
will be discussed with the hardware design of the Series 
500 in the May issue, which will conclude the story of the 
development of the HP 9000 Series 500 Computers. 

Software Organization 

The software for the Series 500 is modular and is easily 
decomposed into smaller building blocks. The design kept 



the internal SUN operating system clearly distinct from 
the code for the BASIC language. This separation was 
necessary to provide the foundation for a true multilingual 
system. For example, we knew that the Series 500 with 
virtual memory would be an excellent FORTRAN engine. 

The separation or layering of the software made it neces- 
sary to define a powerful and flexible set of operating sys- 
tem entry points to support the real-time event-driven 
BASIC language needs. This set of underpinnings also 
serves as the basis for the HP-UX system. 

The SUN operating system hides most of the hardware 
details from the higher-level subsystems. The initial ver- 
sion of SUN supports the Model 520's demanding 700- 
keyword BASIC language with its new run-time compiler. 
The support for multiple CPUs and I/O processors was 
designed in from the beginning. The BASIC language sys- 
tem supports memory-resident programs and data, but does 
not support virtual memory. Besides the BASIC language 
mainframe code, several option packages extend its capa- 
bilities by adding two- and three-dimensional color 
graphics, HP's IMAGE data base management and query 
system, extended I/O. extended mass storage with multiple 
disc formats, multitasking, advanced programming such as 
matrix manipulations, and I/O drivers for a variety of inter- 
faces and devices. BASIC'S highly integrated human inter- 
face causes it to be provided only on the Model 520, the 
integrated desktop version of the Series 500, Special 
hardware in the Model 520's display unit is used to achieve 
excellent performance for BASIC'S text and graphics win- 
dow facilities. The Model 520 keyboard contains special 
control keys used in BASIC, such as RUN, STOP, STEP, and 
PAUSE, in addition to the keys normally found on a terminal 
keyboard. 

We chose UNIX as the best available environment to 
support FORTRAN and other standard languages. A second 
version of the SUN operating system was built using the 
modules from the first version, but with the important virtual 
memory feature added. The diagrams in Fig. 2 and Fig. 3 
show the similarity of the BASIC and HP-UX systems. This 
leverage paid off handsomely, because almost from the 
beginning, the terminals, discs and printers worked reliably 


























Fig. 2. Block diagram ol the BASIC language system lor the 
HP 9000 Model 520 Computer. 
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for HP-UX. Also, the real-time and multiprocessor design 
carried over to HP-UX to give it a more solid basis for 
performance extensions, device L'O. and real-time than 
could be achieved with a ported system. 

A thin layer of code maps the HP-UX intrinsic calls into 
the underlying SUN intrinsics. The same HP Structured 
Directory Format (SDF) hierarchical file system used by 
BASIC is also used by HP-UX. It is almost indistinguishable 
from the System III UNIX file system except that it is more 
reliable and less susceptible to corruption from power fail- 
ures and system crashes. This layered design was a concern 
because it could lead to deviations from the UNIX seman- 
tics defined by Bell Laboratories. Therefore, a set of exten- 
sive and comprehensive kernel test programs was devised to 
determine if any detectable differences had been introduced. 
With only a small additional effort, the layered kernel 
passed the validation tests. The same set of test programs 
is being used to verify the Series 200 HP-UX kernel and 
future releases of the Series 500 kernel. 

The commands and libraries offered are selected from 
both the Bell Laboratories and the University of California 
at Berkeley versions of UNIX. Those most needed for pro- 
gram transport and development are included. The three 
user program languages offered are C. Pascal, and FORTRAN 
77. The calling sequences allow mixing of languages at the 
subroutine level and the sharing of all library routines. 

The definition of HP-UX includes not just compatibility 
with Bell Laboratories' UNIX System III, but also HP exten- 
sions. The current system offers IMAGE data base manage- 
ment, AGP/DGL graphics, and local area networking based 
on ARPANET TCP/IP and Ethernet protocols with both file 



HP-UX 
SUN 




















Fig. 3. Block diagram of the HP-UX operating system for the 
HP 9000 Series 500 Computers. 

and process services. 
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The Development of a BASIC Language Subsystem 



The development of the BASIC language subsystem tor the 
HP 9000 Model 520 Computer had one primary goal — to allow 
this new workstation to be a complete functional replacement 
for the HP 9835 and HP 9845 Computers 1 while achieving at 
least ten times the performance of the HP 9845 by using HP's 
new 32-bit NMOS-III custom VLSI chip set. 2 In addition, new 
features were needed to keep pace with the new applications 
that such a capable machine would encompass. The develop- 
ment schedule for this top-of-the-line BASIC machine ran in paral- 
lel with the chip set development 

The design team decomposed these high-level goals into many 
challenging technical goals, uppermost being to provide a 
growth path for HP's current BASIC language customers through 
a high degree of compatibility, and to add new functions suited 
to the power of the new hardware. The BASIC language was 
unified and extended in cooperation with the Series 200 Comput- 
ers 3 language team while retaining a high degree of program 
compatibility with the earlier HP 9835 and HP 9845. Thus, pro- 
grams from either generation of machines move easily onto the 
Model 520 Almost no differences are notable between Series 
200 BASIC and Model 520 BASIC Even though most HP 9845 
statements are retained, the uniformity of the evolving language 
dictated that some differences would result. An optional translator 
for HP 9845 programs to achieve a more precise semantic match 
is available. 

The maior technical contribution to support the performance 
goals was a run-time compiler for the BASIC language. This 
compiler appears to the programmer to be the same as our 



traditional interpretive environment, preserving such features as 
tracing, line stepping, execution of statements from the keyboard 
and manipulation of a running program's variables. A running 
program can be paused, lines can be added, deleted, or mod- 
ified, and execution then continued from its point of suspension. 
All of these features are still supported even though the user's 
program is not interpreted, but compiled into object code and 
directly executed 

The resulting high-productivity programming environment uses 
execution modes and trap instructions built into the new proces- 
sor Parallel chip set and software development allowed many 
specialized instructions to be added to the processor in support 
of these interactive features as well as the language itself. These 
included some of the traps, the string manipulation set, and bit 
manipulation. The resulting BASIC language system has over 
700 keywords that encompass significant data base manage- 
ment, graphics and I/O capabilities 

The new compiled environment retains the event-driven, real- 
time program control of the HP 9845 and HP 9000 Model 226 
Computers. Program branching and flow are tied to both 
hardware and software events through the use of ON statements. 
These statements define the asynchronous branching that is to 
occur when selected events happens 

Also in support of the performance objectives, the new machine 
uses the emerging IEEE binary floating-point mathematics stan- 
dard instead of the traditional decimal mathematics In addilion 
to making use of the fast microcoded floating-point on the micro- 
processor, binary mathematics is used in new algorithms for 
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computing transcendental and other functions which are both 
faster and more accurate. 

Multitasking was added to improve the user's access to the 
machine and to use the improved processor power. Simultaneous 
program execution and development are now supported. Up to 
60 user processes can be run simultaneously. These processes 
share the system resources and peripherals. For communciations 
and synchronization they have "named-event" signaling. Memory 
resident volumes and files were added for rapid shared-data 
access. File locking allows for atomic (indivisible) update of a 
shared file. 

The system architecture provides for multiple identical CPUs. 
This feature was incorporated into the operating system so that 
the power of many processors could be directed at runable 
tasks. The fundamental design supports these multiple CPUs as 
homogeneous and anonymous computing resources. Since all 
CPUs have symmetric access to all I/O, there is no need to 
introduce master-slave relationships. The only externally visible 
effect of adding more CPUs is increased throughput. 

Full-screen editing and multiple user-defined windows in both 
graphics and alpha displays were added to improve the human 
interface. Both public and private windows are supported, includ- 
ing arbitrary window overlap and last update priority display. 
These windows act much like sheets of paper on your desk, with 
the topmost sheets occluding the sheets below where they over- 
lap. The window structure is dynamic — even the system message 
areas can be relocated anywhere on the screen. 

An example of new hardware capability that mapped into a 
new set of language features is the internal, nonvolatile, real-time 
clock, which facilitates using time to schedule program events. 
The new file system also uses the clock to time-stamp files as 
they are created or changed and the lister dates hard copy 

The graphics definition was extended to support multiple input 
devices with tracking and event capture, and the transformation 
pipeline includes both two- and three-dimensional modeling 
modes. 

Development Tools 

A very accurate emulation program that mimicked the execu- 
tion of the new machine's instruction set was written for execution 
on the distributed HP 9845 workstations. This software emulation 
was so accurate that it took only ten minutes from the time the 
first chip set was delivered to the software team until the system 
was up and running a BASIC program in compiled code on the 
new Model 520 hardware. 

The instruction set" of the new VLSI CPU chip provided the 
hooks for a highly interactive symbolic debugging tool. This de- 
bugger provided a simple transition between running and step- 
ping of systems programs. Procedure, line, and assembly level 
stepping are selected on the fly Program flow is displayed sym- 
bolically at the appropriate level. Variables can be referenced 
symbolically. 



Pascal was chosen as the systems programming language 
with extensions for separate modular compilation to suppon large 
team program development. This new language is called MOD- 
CAL for MODular PasCAL MODCAL is very similar to Wirlh's 
Modula II, but was designed independently by HP For the pro- 
gramming environment, the UCSD (University of California at San 
Diego) p system was selected because it was written in Pascal, 
was easily ported to the HP 9845, and had the other tools, such 
as editors, that were needed 

Another important decision was to separate the BASIC lan- 
guage from its operating system support Clear separation of 
the operating system provided code that could be leveraged for 
Ihe HP-UX project and reduced the cost of maintaining the Model 
520 BASIC system. The underpinnings for the HP 9000 multiple- 
CPU HP-UX system are the same operating system modules 
used for BASIC. 

Over 750K bytes of code are in the BASIC system for the 
Model 520, forming the most powerful program development 
environment ever provided for an HP desktop computer system 
The resulting system's speed, graphics, and real-time, event- 
driven I/O capability make it a very powerful engineering tool. A 
large number of HP 9845 and Model 226 programs have been 
easily moved onto the Model 520. Performance gains average 
50 to 100 times the performance of the HP 9845B Computer and 
more than 10 times the performance of the HP 9845. option 200. 
for computation-limited tasks. The same computational tasks av- 
erage 15 times faster than on the BASIC version of the Model 
226 Computer 
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HP-UX: Implementation of UNIX on the 
HP 9000 Series 500 Computer Systems 



by Scott W. Y. Wang and Jeff B. Lindberg 



AN IMPLEMENTATION of the UNIX " operating sys- 
tem kernel has been layered on top of an existing 
operating system kernel for the HP 9000 Series 500 
Computer Systems. The mapping of UNIX functional re- 
quirements onto the capabilities of the underlying operat- 
ing system is discussed in this article, along with the im- 
plementation of UNIX commands and libraries. These 
pieces of UNIX, along with other extensions added by HP. 
make up the HP-UX operating system. 

The HP-UX operating system is compatible with Bell 
Laboratories' System III UNIX, and supports most of the 
standard UNIX commands and libraries. A number of ex- 
tensions are available, including 
x FORTRAN 77 
« HP Pascal 

■ C 

I HP's AGP three-dimensional and DGL two-dimensional 
graphics subroutines 

■ LAN 9000, an Ethernet-compatible lOM-bit/s local area 
network 

■ The vi visual editor 

■ Virtual memory 
a Shared memory 

■ HP's IMAGE data base management system 
n Support of symmetric multiple CPUs. 

HP-UX Operating Environment 

There are three levels of software in a UNIX system: 
commands, libraries, and kernel intrinsics (Fig. 1). The com- 
mands are user-level programs which can call libraries or 
kernel intrinsics. Some commands are provided with the 
operating system as standard utilities. One example is the 
command interpreter, or shell. Commands can also be writ- 
ten as normal user programs by the user. Libraries are also 
user-level code, but can be called only from a programming 

UNIX is a U S trademark of Bell Laooraloties 



Commands 




Kernel Intrinsics 



Hardware 



language such as FORTRAN or C. Kernel intrinsics can be 
called (normally as functions) from user programs or li- 
braries, and provide a fundamental set of operating system 
operations. 

UNIX Kernel Overview 

A standard UNIX kernel provides support for I/O. file 
system access, process management, real-time clock access, 
memory allocation, etc. The set of kernel intrinsics is fairly 
small and simple; only basic operations are supported by 
the kernel. For example, file manipulation operations such 
as copying files are done by commands. The command 
interpreter shell is another capability that is implemented 
in a user program instead of inside the kernel. 
Process Management. The UNIX kernel supports the crea- 
tion of asynchronous processes that run in the background 
while the user executes other interactive programs in the 
foreground. Intrinsics are provided for the creation, termi- 
nation, and synchronization of processes. Special events 



Typical HP-UX Commands 

Commands in HP-UX are run by entering the name ol the 
command. For instance, to list the contents of the current working 
directory, enter is This causes a program by that name (which 
may be located in one ot several default directories) to be loaded 
into memory and to begin executing Other examples of HP-UX 
commands are 



Fig. 1 . UNIX consists ot three levels ol software— commands, 
libraries, and kernel intrinsics. 



cd dirpalh 
pwd 

vi filename 

rm filename 
cp filename desldir 
cat filename 
cal filename I wc 



Is- 1 



Change the working directory to the 
directory indicated by dirpath 
Prints the full path name (filename) of 
the current working directory 
Invoke the visual editor to edit file 
filename 

Remove file filename 
Copy file filename into directory desldir 
Print the contents of file filename 
Print the number of lines, words and 
characters contained in file filename 
wc is the word count command and its 
input, in this case, is the output of the 
cat command (due to the pipe created 
by l) 

List the contents of the current work- 
ing directory The -I is an option 
that tells the Is command to emit 
additional information Most com- 
mands accept one or more options. 

■Michael L. Connor 



MARCH 1984 HEWLETT-PACKARD JOURNAL 7 



© Copr. 1949-1998 Hewlett-Packard Co. 



are noted by sending signals lo one or more processes from 
other processes or from the kerne). The kernel manages 
identification fields, such as process ID, user ID, and group 
ID, which uniquely identify a process or group of processes. 
The exec intrinsic loads a user program (code and data) 
into memory from an executable file. The memory model 
of UNIX is very simple. It consists of the user's program, 
an execution stack, and a dynamic heap which can be 
extended or contracted via a kernel intrinsic. 
File Manipulation. The UNIX file system is built around 
a hierarchical directory structure, allowing a directory to 
contain other directories as well as normal files. Kernel 
intrinsics are provided to create files, directories, and spe- 
cial files (devices that are in the filename space). The kernel 
also supports creating and deleting links (alternate names) 
to files and getting or setting file access modes. A significant 
feature is the ability to mount a separate disc volume logically 
onto a directory in an on-line volume. This means that all 
on-line volumes are part of a single directory hierarchy. 
File Access. A single set of I/O intrinsics provides transpar- 
ent access to files, devices, or the standard input of other 
processes. A program normally does not know whether its 
standard input is coming from a file, a device, or another 
process via an interprocess pipe. Standard operations are 
provided, including read, write, open, close and status. 
Special device control is provided via the iodl intrinsic. 
Miscellaneous. Several other features are supported by the 
standard UNIX kernel, such as real-time clock access, log- 
ging accounting information at process termination, and 
profiling the execution of user programs. The profiling and 
accounting facilities have not yet been added to HP-UX. 

SUN Operating System Kernel 

When the HP 9000 project began, the operating system 
designers took a different approach from that used on HP's 
previous desktop computers. Even though the first HP 9000 
language system was to be an extension of the BASIC lan- 
guage system of the HP 9845 Computer, an objective of the 
operating system design was to allow other languages in 
later versions of the product. The system software was 
designed in a modular, layered fashion (see Figs. 2 and 3 
on pages 4 and 5). A central operating system kernel provides 
a high-level interface to the hardware and machine architec- 
ture, while other subsystems provide more specific func- 
tions layered on lop of this kernel. This operating system 
kernel, called SUN, is described in detail in the article on 
page 28. 

SUN is written mainly in MODCAL, an enhanced version 
of Pascal. MODCAL supports information hiding* via mod- 
ules, an elegant error recover}' mechanism, and systems 
programming extensions such as absolute addressing. A 
small part of SUN is written in assembly language. The 
SUN kernel is not visible to the user; instead, it relies on 
upper-level subsystems such as BASIC or HP-UX to provide 
a user interface. The major pieces of the SUN operating 
system kernel handle power-on initialization and memory 
and process management, and coordinate the file system, 
drivers, I/O primitives, real-time clock, and interprocess 
messages. 

"Information hiding is a software design approach where Ihe Inner workings ol an individual 
section are Kepi "hidden" trom olher sections This allows a section to be changed or 
updated with minimal concern about its effects on other sections 



An unusual feature of the file and I/O system is the ability 
to add new directory format structures, device drivers and 
interface drivers. These modules can be added without 
affecting the existing SUN kernel code. 

Some key pieces are missing from SUN by design , notably 
the human interface and program loader. The BASIC sys- 
tem provides its own human interface code, which uses 
the integrated CRT and keyboard of the Model 520, the 
desktop version of the HP 9000 Series 500 Computers. HP- 
UX provides a terminal-style human interface to communi- 
cate with the user through the integrated CRT and keyboard 
as well as through normal terminals. HP-UX and BASIC 
also provide their own program loading facilities. 

HP-UX Kernel Strategy 

The basic strategy of the HP-UX implementation is to 
layer the HP-UX kernel definition on top of the SUN kernel. 
The exact System in UNLX semantics and syntax are kept, 
but the HP-UX intrinsics are implemented using SUN ker- 
nel support instead of porting the Bell Laboratories kernel 
implementation to the Series 500. 

A layer of code called the HP-UX layer resides just above 
(and in some cases beside) the SUN kernel, as does the 
BASIC subsystem. However, BASIC and HP-UX are mutu- 
ally exclusive; only one can be loaded at a time. 

The HP-UX layer performs any necessary transforma- 
tions between UNIX formats and the corresponding SUN 
formats (e.g., the real-time clock format). It calls procedures 
in SUN whenever appropriate, but still has full access to 
the hardware and architecture when needed. The HP-UX 
layer maintains a number of higher-level data structures 
to manage HP-UX user processes and user resources. 

This layering strategy has a significant impact on the 
implementation detail of the HP-UX layer. For example, 
MODCAL is used instead of C as the implementation lan- 
guage. However, user-level code written for System III 
UNLX will run on HP-UX, unless it depends on certain 
internal implementation details such as the directory for- 
mat structure or invisible internal system data structures. 

The advantages of this layering approach come in two 
main categories — leverage and opportunities for contribu- 
tion. A large portion of hardware-dependent code was al- 
ready written for the Series 500 and its peripherals. Using 
the SUN kernel made it unnecessary to rewrite this code 
for HP-UX. Existing modules used include device and in- 
terface drivers — especially significant because of the com- 
plexity of the HP-IB (IEEE 488) and the new HP CS-80 
discs — low-level memory management, power-up code, 
process scheduler, architecturally dependent utility rou- 
tines, and other machine-dependent code. 

SUN has a number of features that are not present in 
UNIX; these features provide opportunities for 
HP-UX to make a contribution over other UNLX implemen- 
tations. These include real-time performance in the area 
of interrupt response time and process switching, support 
for multiple CPUs, reliability in the face of system errors, 
support for variable-size independently managed dynamic 
memory segments, semaphores, and low-level device I/O 
capability. Also, HP's IMAGE data base management sys- 
tem was already implemented on top of SUN for the BASIC 
system. This code was ported to the HP-UX environment 
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What is UNIX™? 



The popularity of the UNIX" operating system developed by 
Be" laboratories has been increasing smce it became opera- 
tional m 1971 Today, it is rapidly becoming the most popular 
operating system for mid-sized compulers and runs on numerous 
machines made by different manufacturers There have even 
been those that have likened UNIX's role in operating systems 
today to FORTRAN s role in computer languages some twenty 
years ago. 

UNIX was developed by Ken Thompson and Dennis Ritchie 
of Bell Laboratories Both men had been working on a project 
called Multics (an acronym for multiplexed information and com- 
puting service), which was a large multiuser operating system 
thai was eventually cancelled by Bell Laboratories From there. 
Thompson, and then Richie, went on to develop UNIX As you 
might expect, many of the more desirable features found in Mul- 
tics were incorporated in ihe UNIX design. In fact, even the UNIX 
name was adopted from a playful twisting of "Multics." 

As the years went by, the UNIX systems within Bell Laboratories 
evolved until version six (V6) was developed about 1975 This 
version became quite popular in a number of universities around 
the world, including the University of California at Berkeley (UCB) 

Version seven was released in 1978 and quickly replaced V6 
m most installalions This version is the base for most of the 
commercial UNIX look-alikes, of which the Xenix system de- 
veloped by Microsoft is probably the best known It is also the 
version on which UCB built their popular enhanced versions of 
UNIX. Each UCB version released contained a few enhance- 
ments over the previous releases UCB's versions are designated 
by xBSD, where x is the version number and BSD stands for 
Berkeley Software Distribution 4.2BSD is the most recent. 

In early 1982, Bell Laboratories released System III UNIX. This 
version is the base for HP-UX (HP's version of UNIX), although 
HP-UX also incorporates some of the nicer features found in 
UCB's 4.1 BSD version. 

Syslem V UNIX was released by Bell Laboratories in 1983. 
Bell is guaranteeing that all of their future UNIX versions will be 
compatible with System V 

UNIX Popularity 

Exactly why UNIX has become so popular is a hard question 
to answer, bul Ihe reasons probably include 

■ Simplicity. The UNIX system can be broken into fairly small 
independeni pieces. Each piece can be comprehended indi- 
vidually and ai a pace thai is comfortable for a user Few users 
ever need lo learn all the features provided by UNIX. 

■ Power. The pieces of the system can be connected synergis- 
tically and manipulated at execution time, the I/O can be redi- 
rected, the outpul of one process can be connected lo the 
input of another (forming a "pipeline" of arbitrary length), pro- 
cesses can be executed in foreground or background, a com- 
mand list can be developed and then executed when desired 
and as often as desired, etc. 

■ Flexibility. Pieces of the UNIX system are easily added, re- 
placed, or deleted. System reconfiguration is quick and 
straightforward. 

■ Software Bell Laboratories. Hewlett-Packard, and a lot of other 
companies and individuals have pui a lot of effort into develop- 
ing a large software base that runs in the UNIX environment. 

UNIX is a U S trademark ol Bell Laboratories 



■ Ease of porting Most of the UNIX system « wntten m a 
machine-independent manner It has been ported to a num- 
ber of different computer architectures with relatively few 
problems 

Features 

UNIX has many features Some of them are. 

■ The shell The shell is a program that provides the interface 
between the user and the UNIX system It is a command in- 
terpreter that takes input from the user and executes the re- 
quested commands It can also take input from an ASCII com- 
mand file, which is generally referred to as a shell script " 
When a command is executed, it can be passed arguments, 
have its standard I/O files redirected, and/or be placed in the 
background, all through provisions built into the shell The 
shell also has flow control structures that allow conditional and 
multiple execution of command lists Because of the flexibility 
of UNIX, the shell can be replaced by a different program In 
fact. UCB has chosen to do |ust that and provides their own 
version of the shell called the C shell. 

■ The C Language C was developed concurrently with UNIX 
at Bell Laboratories. It is a medium-level language with many 
of Ihe features found in Pascal and other high-level languages 
It provides a programmer with a lot of power and few con- 
straints. Most implementations of Ihe UNIX kernel and most 
of Ihe UNIX commands are written in C. 

0 Other languages. Currently HP-UX on HP's HP 9000 Series 
500 and Series 200 Computers offers compilers for Pascal 
and FORTRAN 77 in addition to C. 

■ Full set of commands Commands lo maintain the UNIX system 
and the file syslem. editors, lext processors, and numerous 
other commands are included in HP-UX, The popular vi editor 
from UCB is included in Ihis set. 

a A rich set of library routines. These include routines to compute 
common math functions, to perform formatted I/O. lo access 
kernel intrmsics, and, on the HP 9000 Series 500 Computers, 
routines to manipulate virtual memory objects, lo do DGL/AGP 
graphics, and lo access an IMAGE data base 

» Data communication support System III and other versions 
of UNIX provide a set of UNIX-to-UNIX copy (uucp) services 
lo allow the user to pass flies from node lo node in a UNIX 
network A sophisticated electronic mail system has been im- 
plemented by using these services. To Ihese, Ihe HP 9000 
Series 500 Compulers add a local area network (LAN 9000), 
general terminal emulator capabilities, and remote |ob entry 

■ Source code control system (SCCS) This is a set of commands 
that helps the programmer keep track of changes lo source 
files 

Further Reading 

1 H McQillon and R Morgan. Introducing the UNIX System. McGraw-Hill 1983 A 
good tutorial 

2 R Thomas and J Yates. A User Guide to the UNIX System OSBORNE/McGraw Hill 
Berkeley. 1962. Another good tutorial 

3 Bell System Technical Journal. Vol 57 no 6, Pari 2, July- August 1978 The entire 
issue is dedicated lo UNIX ot about version seven 

4 HP-UX fle'erence Manual, Hewlett-Packard Publication 09000-90004 A good refer- 
once, but not easy lor a novice to understand 

5 HP UX Selected Articles. Hewlett-Packard Publication 97089-90002 Nineteen arti- 
cles on some ol the targe components lound m UNIX 

6 S R Bourne. The UNIX System. Addison-Wesley 1983 A good introduction 

■Michael L. Connor 
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to provide this important HP standard data base capability. 

An important concern was the performance of a layered 
implementation; the risk was that conversion between the 
SUN format and the HP-UX format would increase operat- 
ing system overhead. The experience actually observed 
after the product was completed was that the HP-UX layer 
itself is responsible for approximately 1 0% of the CPU time 
used by the kernel, and nearly all of that time is spent 
doing useful work such as loading programs. This means 
that SUN is a fairly good match for the HP-UX requirements, 
because little time is wasted on conversion between SUN 
and HP-UX formats. 

Matching SUN and HP-UX 

This section describes the areas of the SUN operating 
system that were changed or augmented to support the 
requirements of HP-UX. Only areas that are important to 
mapping the UNIX semantics onto the original SUN kernel 
are described in depth. 

File System. There was already a good match between the 
SUN operating system and HP-UX in the hierarchical direc- 
tory structure of the file system. The existing directory 
format was modified to fit HP-UX semantics rather than 
implement the standard UNIX disc format in MODCAL. 
The fundamental operations such as read, write, open, and 
close were already supported in a satisfactory manner in 
SUN; no significant changes to these were necessary. 

However, the file system itself was the area that required 
the largest changes in SUN. One of the biggest additions 
was the support of device files, special files that map de- 
vices such as printers or terminals into the same name 
space as regular files. The SUN file system expected device 
and file accesses to be made separately. Special checks had 
to be made for special file types; the new device file code 
performs operations for device files equivalent to those 
originally performed only for regular files. 

Another large change was support for mounting disc vol- 
umes onto an on-line directory so that all accessible files 
and directories are part of a single directory hierarchy. 
Again, special code was added to check each directory 
access; if the directory has another volume mounted on it, 
the access is redirected to the root directory of the mounted 
volume. 

The third area of major change was file access protection 
semantics. The UNIX read/write/execute and user/group/ 
other mechanisms used to control access to files were not 
originally in the SUN file system protection scheme. This 
could have been added, along with the standard UNIX disc 
format structure, to a separate directory format module, 
since SUN supports multiple directory format structures. 
However, the characteristics of the existing format were so 
close to those desired that the SUN format and protection 
scheme were adapted to the HP-UX requirements instead. 

Changes were made in the SUN file system to support 
pipes and FIFO (first-in, first-out) files. In the early versions 
of HP-UX, pipes were implemented in the HP-UX layer. 
However, they have been moved inside the SUN file system 
for performance reasons. A number of minor HP-UX file 
system operations had to be added to SUN. These include 
changing the owner of a file, reading or changing file access 
modes, and duplicating an open file descriptor. 



Some operations are performed in the HP-UX layer. 
These include parsing multilevel path names, managing 
the user's open files table, and enforcing file size limits on 
extending files. 

I/O. In the area of device I/O. the existing SUN I/O system 
was a very good match for the needs of UNIX. Virtually no 
changes were made to the I/O primitives that provide the 
interface to the backplane and I/O processor, the bus 
bandwidth management code, the drivers for interface 
cards, or the disc and tape device drivers. 

The major changes came in the internal and external 
terminal support. The external terminal driver is based on 
the existing serial interface driver, but adds UNIX try seman- 
tics such as type-ahead, line buffering, mapping carriage 
return/line feed to newline, and sending the interrupt and 
quit signals. The Model 520 Computer's integrated keyboard 
and CRT device control code is based on the work done 
for the BASIC system's human interface. But the functional 
operation of the integrated "terminal" had to be completely 
redone to be compatible with HP terminals. 
Memory Management. Because of the simple memory 
model of HP-UX, the memory allocation intrinsics are eas- 
ily supported on most operating systems, including the 
SUN kernel. The major changes in the SUN memory man- 
agement system were required by the addition of virtual 
memory and shared memory, which are extensions rather 
than semantic requirements of UNIX. The HP-UX layer has 
the responsibility of keeping track of the user's memory 
use and deallocating this memory when a process or pro- 
gram terminates. 

Program Loading. No explicit function for loading and 
executing programs is present in the SUN operating system, 
but the underlying support needed is there. The file system 
is used (with minor changes) to find and read the program 
file, and the memory management system provides the 
mechanism for allocation of code and data segments. No 
major changes were required in the SUN kernel to support 
program loading. 

The HP-UX layer manages shared code segments, which 
allow multiple processes to share a single copy of the code. 
The HP-UX layer also handles relocation of code and data 
segments at load time and meets the segment attribute re- 
quirements requested by the object file format. 
Process Management. The HP-UX process management in- 
trinsics are supported fairly well by the SUN kernel, but 
two areas required a significant effort: fork and signal. The 
fork system call creates a new process in the exact image 
of the calling process. It returns to both the parent and 
child processes, just after the fork call, at the point where 
the function return value distinguishes the child from the 
parent. Creating an exact copy of a process is not a typical 
operation supported by normal operating systems, includ- 
ing the SUN kernel. 

At the SUN level, code was added to support the "clon- 
ing" of a process. The cloning operation allocates memory 
for the child process and initializes SUN modules for the 
new process. It is also responsible for duplicating the con- 
tents of the parent's segment table in the child's segment 
table and creating an exact image of all the parent's seg- 
ments in the child's address space, including virtual mem- 
ory segments and the stack segment. 
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The HP-UX layer then initializes the new process. This 
includes allocating an HP-UX process control block, copy- 
ing some fields from the parent's process control block, 
and initializing other unique fields such as process ID and 
parent process ID It also increments use counts on shared 
objects such as shared code segments and open files. Fi- 
nally, the HP-UX layer returns the appropriate value to the 
parent (child's process ED) and to the child (zero). 
Signal Implementation. The implementation of signal, a 
mechanism for interprocess event notification and excep- 
tion reporting, was a significant portion of the HP-UX layer 
development. SUN had no explicit support for sending 
asynchronous signals between processes, but did have most 
of the tools necessary to implement this feature. 

One tool is the ability of subsystems to install trap han- 
dlers for most classes of traps possible on the Series 500 
Computers. Signal processing is initiated by triggering an 
Ml (machine instruction) trap in the target process, which 
causes the Ml trap handler to be entered on the next machine 
instruction executed. This handler is responsible for pro- 
cessing the signal received and taking the specified action. 
This can be calling a user-specified signal handler, ter- 
minating the process, or just ignoring the signal. 
Other Process Management. The process scheduler met 
the requirements of HP-UX in the original SUN implemen- 
tation, but has been improved to allow dynamic process 
priority adjustment to reward interactive processes. (It is 
currently being enhanced to suspend low-priority pro- 
cesses during heavy system loads.) SUN supports the cre- 
ation of special system processes that can provide specific 
system services. These system processes communicate 
with user processes and each other via SUN's mailbox-style 
interprocess messages. Also, a sophisticated set of 
semaphore operations is provided for synchronization of 
all processes in the system. This is especially important in 
a multiple-CPU system: merely disabling interrupts does 
not ensure exclusive access to a shared data structure, be- 
cause other processes may be running simultaneously on 
other CPUs. 

The following process management functional areas are 
implemented in the HP-UX layer: 

■ Higher-level support of fork such as allocation and in- 
itialization of a process control block for the new HP-UX 
process 

■ Higher-level support of signal, including sending and re- 
ceiving signals, and specifying action to be taken on 
receipt of a signal 

■ Management of user, process, and group IDs 

■ Process termination, including deallocation of resources 
owned by the user process 

■ Wait for a signal or for termination of a child process 

■ Management of HP-UX process control blocks. 

The functional areas listed below are completely sup- 
ported by the SUN kernel, except for those changes noted. 

■ Power-up 

■ Multiple-CPU support 

■ Trap handling 

■ Real-time clock: the HP-UX layer performs the conver- 
sion between SUN time format and HP-UX time format 

■ Alarm clock: the HP-UX layer creates a system process 
that wakes up each second to see if any alarm signals 



need to be sent 
■ CPU times; a minor change was made to the timer inter- 
rupt service routine to increment the CPU time used by 
the current process. 
Upper-Level Software Strategy 

Working in parallel with the SUN and HP-UX kernel 
design groups was another group of software engineers 
who were responsible for the upper-level commands and 
libraries. The UNIX system from Bell Laboratories contains 
more than 300 commands and over 200 library subroutines. 
Consisting of more than 300.000 lines of C source lines, 
these constitute the bulk of the UNIX system. The majority 
of HP-UX upper-level software on the Series 500 Computers 
is based on these UNIX System III commands, plus several 
from the 4.1 BSD version of UNIX from the University of 
California at Berkeley (UCB). 

For implementation priorities, the upper-level software 
team first categorized the commands and libraries into dif- 
ferent groups based on their usefulness. For example, in- 
itialization and file manipulation commands were all in 
the first group. Useful tools were in the second group and 
other commands and libraries, such as those used for text 
processing, were in the third group. Then the C source 
code of the first two groups was studied in some detail 
using a C cross referencer to determine which system intrin- 
sics and libraries were used. The data resulting from the 
study was stored in an HP 9845 IMAGE data base from 
which many useful reports were produced. For example, 
a system intrinsic implementation priority list was gener- 
ated based on the highest-priority commands to guide the 
kernel group in their implementation. As new system in- 
trinsics were brought up, the upper-level software team 
was able to determine from the data base what additional 
commands could be brought up with the newly available 
intrinsics. 

Another IMAGE data base was used to keep track of all 
commands and libraries in terms of implementation prior- 
ity, responsible engineer, porting status, source origin, etc. 
This proved to be very useful for managing the project and 
keeping other departments informed about the status of 
each command. 

Porting Commands and Libraries. Four major tools were 
necessary to port the upper-level software: a C-to-HP-9000 
cross compiler, an assembler, a linker, and a cross compi- 
lation machine. The upper-level software team used a re- 
motely accessible VAX/750 running UCB UNIX as the cross 
compiling environment. Other tools to move files to and 
from the VAX/750 were developed as necessary- 
After the initial system was up and running, the major 
focus was to make the C compiler resident on the Series 
500 by cross compiling it. We had a resident environment 
two months later. From that point on. all development 
work was done on a Model 520 Computer running the 
latest (sometimes experimental) kernel. The upper-level 
software development system then grew from one single- 
user system to two multiuser systems linked with a local 
area network. 

The majority of the commands and libraries were ported 
over to the Series 500 with little or no modification, that 
is, most of them ran after compilation. However, the follow- 
ing types of changes were necessary. 
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HP-UX: A Corporate Strategy 



With the introduction ot HP-UX on the HP 9000 Series 500 
Computers, Hewlett-Packard has made a strong commitment to 
the use of an enhanced version ot UNIX '" as a standard operating 
system for its new computer products. Through this commitment, 
HP is striving to eliminate unique software attributes that make 
end-user programs difficult to "port" from one computer to 
another Programmers can now design their software to run on 
an array of HP machines, concentrating on modularizing and 
scaling their applications to best suit each computer's price/per- 
formance characteristics. 

Why UNIX? 

Since any operating system standard would simplify the porting 
process and improve programmer productivity, why was UNIX 
selected as the heart of HP's software strategy? 

UNIX is gaming wide acceptance as an industry standard for 
16-bit and 32-bit minicomputers. Its popularity is partially be- 
cause it has been easy to implement on a variety of processors 
and computer architectures. This portable characteristic made 
UNIX an ideal choice as a compatible operating system for the 
distinct architectures of current HP 9000 members: the 16/32-bit 
68000 microprocessor-based Series 200 Computers (Models 
220 and 236) and HP's proprietary 32-bit VLSI-based Series 500 
Computers (Models 520, 530, and 540) UNIX is also planned 
for future members ot the HP 9000 family. 

The popularity enjoyed by UNIX has a synergistic effect. Soft- 
ware applications are being designed for the UNIX environment 
at an increasing rate, which in turn encourages more UNIX im- 
plementations. Most of this software will run on HP-UX, thereby 
making HP's computers more attractive to a larger audience. 
Furthermore, UNIX is studied and taught in most major univer- 
sities. Today's computer science graduates will eventually influ- 
ence or become those who select computers for commercial 
and scientific use. UNIX-based products are likely to receive 
strong consideration during the selection process. 

What Is HP-UX? 

HP-UX is a combination of Bell Laboratories' UNIX operating 
system, portions of the University of California at Berkeley (UCB) 

UNIX is a U S trademark of Bell Laboratories. 

•Kernel. Libraries 
•C Compiler, vi 
•Other Commands 
•(System V Semantics) 



•System III Kernel, Libraries, 

and Command 
•(System V Semantics) 



implementation of UNIX and Hewlett-Packard software enhance- 
ments. Through UNIX, HP-UX facilitates easy importation of UNIX- 
denved programs and offers a consistent, powerful program de- 
velopment environment. Complementary extensions address the 
Manufacturer's Productivity Network (MPN), HP's view of how 
computer systems can be used in manufacturing organizations 
to improve productivity. 

Rather than implementing every function of Bell Laboratories' 
System III UNIX, features were included based on their impor- 
tance in porting standard software or their absolute program 
development value. Using these guidelines, a compatibility 
hierarchy was developed in which kernel services became a 
"must," library subroutines a "high want," and commands a 
"want." 

As a result of this approach, HP-UX includes all System III 
kernel intrinsics and all libraries except for a handful of graphics 
subroutines. More than 125 of the most useful System III com- 
mands and a small but important number of UCB commands 
are also offered. 

To satisfy customer requirements, enhancements covering 
programming languages, graphics, data base management, de- 
vice and instrumentation I/O, local area networking, and friendly 
user interfacing are being standardized. These extensions, which 
appear as additional kernel intrinsics, libraries, and commands, 
will bridge the gap between HP's HP-UX and non-HP-UX computers. 

Additional enhancements assist in migrating applications soft- 
ware from current proprietary HP operating systems to HP-UX. 
One of these tools, the Applications Migration Package (AMP), 
converts the HP 1000 Computer's RTE calls to HP-UX calls. AMP 
revisions are pianned as HP-UX is expanded to meet real-time 
control requirements. 

New software features are not the only form of HP enhance- 
ments. On-going training allows sales and technical support or- 
ganizations to provide complete services before and after sales. 
Easy-to-read tutorials and reference manuals aid both novice 
and experienced users. Exhaustive R&D software testing ensures 
reliable operation and minimal downtime. 

Since HP-UX is planned for many future HP computers, HP 
will leverage investments already made in these important sup- 
port areas. By avoiding the massive reinvestments continuously 
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Fig. 1. Influence of Bell Lab- 
oratories, UCB. and HP exten- 
sions on the direction of the HP-UX 
definition. 
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required of new software systems. HP can concentrate on improv- 
ing all aspects of HP-UX in the future 

HP-UX Standards Enforcement 

Compliance with the HP-UX standard is enforced through com- 
prehensive sets of validation programs Automated test programs 
monitor proper operation of all kernel intnnsics. System III li- 
braries, two-dimensional and three-dimensional graphics li- 
braries, and the FORTRAN and Pascal compilers As the stan- 
dard evolves, additional validation programs will be developed 
to ensure consistency across all HP-UX computers. 

Overall management of the standard is the ongoing responsi- 
bility of the HP-UX Steering Committee Consisting of represen- 
tatives from several HP divisions, this committee meets monthly 
to resolve pertinent HP-UX issues and to review the status of the 
various HP-UX working groups. These groups, also with broad 
divisional represenlaiion, cover technical, marketing, documen- 
tation, and customer support issues in more detail Each division 
works through its representatives to propose additions or 
changes to Ihe standard. 

Future Direction 

Perhaps Ihe most critical issue m establishing the future course 
for HP-UX is its degree of compatibility with Bell Laboratories 
and UCB While 4.2BSD UNIX (Revision 4.2 Berkeley Software 
Distribution) is currently the superior version, Bell is developing 
improved versions that could eventually surpass 4.2BSD in capa- 
bility and reliability In addition, tour microprocessor manufactur- 
ers* intend to offer System V, Bell's latest UNIX version, on their 
microprocessor products. System V can potentially become the 
most affordable UNIX and thus the UNIX of choice lor portable 
application programs. 

■Intel. Motorola. National Semiconductor, and Zilog 



■ A new system intrinsic entry point mechanism was de- 
veloped because the kernel was written inMODCAI.and 
the rest of the system was in C. 

■ Some data structures contained in the C header files 
needed to be modified to match the HP-UX layer data 
structures. (Header files contain data and structure decla- 
ration statements for C programs.) The commands that 
needed these header files were examined in detail to see 
if modification was necessary. 

■ A few commands were rewritten completely because the 
kernel was not the original standard kernel. For example, 
fsck, the file system integrity checker and maintainer. 
was rewritten because the SDF (structured directory for- 
mat) file system is physically different from the UNIX 
file system. The process status command ps was modified 
extensively because of data structure differences. 
Another example was the mknod command which creates 
special files to communicate with I/O devices. It was 
modified to match the UNIX semantics to HP-IB I/O de- 
vices. However, all the commands were kept as compat- 
ible as possible with System III UNIX commands. 

■ The Series 500 supports IEEE floating-point format; as 
a result, the UNIX math library was replaced with HP's 
own implementation. 

■ Twenty-one new commands were implemented that 
Bpply to the Series 500-based HP-UX. These deal primar- 
ily with machine-dependent features such as disc boot 
area management, disc initialization, setting virtual 



In consideration of these factors, the Ben System III version 
has been chosen as the base standard. The compatibility hierar- 
chy will determine wnich portions of System V and rts successors 
are HP-UX candidates 

Extensions beyond the Bell versions can be expected if they 
fail to meet HP requirements in a timely fashion However, we 
prefer to adopt an existing UNIX-based implementation (if one 
exists) before embarking an an original design protect. A poten- 
tially rich source of enhancements currently under investigation 
is UCB's 4.2BSD version We anticipate adding such UCB fea- 
tures as the C shell, mailer, and selected kernel mtrmsics. 

Microsoft's Xenix, with its large installed base and potentially 
rich source of UNIX applications programs, could influence the 
HP-UX standard. Since Xenix and HP-UX are selectively adding 
Bell System V and UCB features to the same System III definition, 
conformance between the two systems is likely. 

Fig 1 illustrates the mapr influence of the HP extensions and 
the Bell releases on the HP-UX direction. It also recognizes UCB 
as a promising contributor of additional functionality. 

In support of low-cost computer systems, we are examining 
methods of subsetting HP-UX without sacrificing compatibility or 
easy growth to the higher-performance systems. Code compac- 
tion and reduction techniques for both the operating system ker- 
nel and the disc resident commands are being considered. An 
exciting technique under investigation is a high-performance dis- 
tributed HP-UX operating system, which allows individual work- 
stations to rely totally on shared network peripherals. Thus, the 
cost per system is dramatically reduced, but local processing 
power is maintained 

HP-UX will be modified to support several European languages 
and the 16-bit Kanji character set Thus, localized application 
program solutions will be possible. 

-Michael V. Hetrick 



memory parameters, and system installation and update. 

The handling of DC600 tape cartridge data on HP's new 

CS-80 discs also required special support. 
Problems During Porting. The problems encountered in 
porting the commands and libraries can be categorized in 
two areas — architecturally dependent and architecturally 
independent. Architecturally independent problems were 
mostly anomalies found in the original UNIX code. We 
logged over 281 new bug reports during the port project. 
Over 60% of these bugs were fixed. The others were either 
classified as not worth fixing or waiting to be fixed. 

Architecturally dependent problems were usually 
caused by dereferencing of nil pointers or dependency on 
the direction of stack growth. On the VAX/750 implemen- 
tation of UNIX, a nil pointer dereference returns a zero. 
On the HP 9000 Series 500 HP-UX, a system trap occurs. 
This architectural dependency is relied on in many places 
in the standard UNIX commands and libraries, and each 
of these needed to be corrected. These usually manifested 
themselves in a memory fault error message. Fortunately, 
this error was relatively easy to fix in the source code. 

The stack grows towards high memory (up) on the Series 
500 and down on the VAX/750. For example, the printf sub- 
routine in the standard I/O library can have a variable 
number of parameters and the pointer used to access the 
parameters on the stack is decremented rather than in- 
cremented. Other architecturally dependent features in- 
cluded the byte order swap of the VAX/750 hardware where 
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low and high bytes are reversed. This made reading cpio 
archive format tapes from the VAX/750 a chore in the be- 
ginning. Now HP-UX defines a new -p option to the cpio 
command which does the byte swap. 

The upper-level software team did not have a user-level 
debugger available to debug the C programs. Instead, the 
kernel-level HP 9000 debugger was used to debug the com- 
mands. It was cumbersome to set up the initial breakpoint, 
but quite effective after that. (A user-level symbolic debug- 
ger is being developed.) 

Shared Libraries. The Series 500 architecture supports 
shared code segments, thus allowing the implementation 
of a special shared I ibrary for major portions of the standard 
C library. That is, there is only one copy of the library in 
the system shared by all system commands that are linked 
in the standard C library. (The shared library feature is not 
currently available to user programs.) This saved typically 
7K bytes of code space for each command (just about all 
of the commands used the C library). This, in turn, im- 
proved load-time performance and saved disc space. 
SCCS and the Build Process. UNIX is touted as one of the 
best program development environments available, be- 
cause it provides many software engineering tools. The 
source code control system (SCCS) is one such tool that 
the upper-level software team took advantage of throughout 
the project life cycle. The SCCS was brought up and used 
as soon as all kernel support was available. The Bell 
Laboratories System III source code was put under SCCS 
as the baseline and all upper-level software changes were 
built on top of it. Each upper-level software team member 
adhered to a simple set of rules that applied to the access 
and update of the controlled source. This proved valuable 
for day-to-day software development, providing who, 
when, how, and why information about code changes. 

SCCS maintains revision numbers to allow access control 
and retrieval of any version of the source code. It also 
supports checksums of the source files to check for corrup- 
tion. This was important since code development was done 
in parallel with the file system development and the 
checksum is a simple physical integrity check. SCCS was 
indispensable later during quality assurance testing and 
the code freeze period just before each major system release. 

System build scripts were written to manage the compi- 
lation of all the commands and libraries from the SCCS 
source directory automatically. The build procedure, along 
with the scripts, was able to handle compiler, assembler 
and linker updates, getting the source, and compiling the 
system in proper sequence. This was important for system- 
wide changes such as object file format changes or major 
updates in the compiler or other tools. The scripts also 
controlled the target file system structure, setting file own- 
erships, access permissions, etc. They also managed the 
SCCS update revision level of each system build such that 
any change occurring after the build started would be at a 
higher level and would not be included in the current build 
even if the build process had to be restarted for some reason. 
The build scripts evolved through the life of the project 
and became a major tool for system releases. The final build 
of the 3.3M-byte system took around 17 unattended hours 
to complete. 



Compatibility 

The upper-level software porting experience indicated a 
high degree of compatibility between the HP-UX layered 
kernel and the UNIX System III kernel. Out of 126 ported 
commands from System III, 57 required no modification 
at all, 44 required less than 10 lines of modifications, 16 
required between 10 and 30 lines of modifications, and 9 
required more than 30 lines of modifications. Most modifi- 
cations were to fix bugs. These commands do not include 
development tools such as a compiler, an assembler, and 
a linker, nor do they include UCB UNIX commands. 

Extensive effort was made to ensure compatibility with 
Bell Laboratories' System III UNIX. First, a "minimum 
touch" strategy on the System III source code was used. 
The design team did whatever was necessary to make the 
commands and libraries work, but beyond that they did as 
little modification as possible. Temptations to clean up the 
code were strongly discouraged. Each reported bug was 
evaluated to determine whether it should be fixed and if 
so, how. 

Second, validation suites* were used to ensure compati- 
bility with System III. The priority for the validation suites 
was to validate the kernel first, then the libraries, and fi- 
nally the commands. 100% of the kernel intrinsics were 
validated. A significant effort was invested in the kernel 
validation suite. It was run after each new kernel was built. 
92% of the subroutine libraries have validation tests and 
all are incorporated into an automatic test suite. 22% of 
released commands have validation tests. The validation 
suites were written with verification of the functionality 
in mind rather than exhaustive quality assurance testing. 

The automatic validation test suite is organized for ease 
of use. There are two types of tests — one related to the root 
user* and the other related to the typical user. The automat- 
ic test suites were provided to the software system integra- 
tion team for testing commands and libraries with other 
major subsystems. 
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An Interactive Run-Time Compiler for 
Enhanced BASIC Language Performance 

by David M. Landers, Timothy W. Tillson, Jack D. Cooley, and Richard R. Rupp 



AT THE BEGINNING of the BASIC project for the HP 
9000 Model 520 Computer, the project team was 
faced with a major challenge. To take full advantage 
of the performance available in the Model 520 from the 
new 32-bit NMOS-III VLSI microprocessor. 1 BASIC had to 
be implemented as a compiled language. Using traditional 
compiler technology, this would mean giving up many of 
the interactive features so popular with current HP 9845 
users. The challenge was to develop a new compiler tech- 
nology that would support these interactive features while 
maintaining the performance advantage of a compiler. 

The breakthrough came in the form of two articles on 
"throwaway compiling." explained in two articles — one 
by P.J. Brown~ and one by J. Hammond. 1 The throwaway 
or run-time compiling technique compiles each line the 
first time it is executed. As more of the program is compiled, 
the performance approaches that of a traditional compiled 
system. If the program runs out of memory, the current 
object code is discarded (hence the term "throwaway com- 
piling") and the incremental compilation is restarted at the 
next line to be executed. 

The authors were looking for a way to run programs 
efficiently on machines with limited memory space, but 
the throwaway compiling technique looked like it could 
be adapted for a run-time compiler that would provide the 
desired interactive features. If the object code could be 
thrown away during the execution of a program and rebuilt 
without restarting, it could also be thrown away at arbitrary 
times such as when the user modifies the program. Within 
limits, the program reconstructed after throwaway could 
be different from the program before throwaway. This 



would support the pause, edit, and continue feature. Given 
that an intermediate form of the program is available to 
reconstruct the object code at run time, this intermediate 
code could be designed to contain enough information to 
support the interactive debugging features. Finally, if the 
object code could be constructed one line at a time and 
added to the object code at run time, the code for a single 
line could be constructed and immediately executed as 
well. This would allow asynchronous execution of single 
lines from the keyboard during program execution. 

Enhanced BASIC Language 

The BASIC language that Brown implemented as part of 
his research was a very minimal subset, whereas Model 
520 BASIC is a substantial language with several significant 
features beyond those supported by most other BASIC sys- 
tems. Could these more advanced features be implemented 
in a run-time compiling environment? That was the ulti- 
mate challenge facing the design team. Some of the lan- 
guage features that presented the biggest challenge were: 

■ Subprograms similar to FORTRAN routines, but support- 
ing recursion. Both subroutine and function subpro- 
grams are supported. 

■ A COMMON statement similar to that used in FORTRAN. 
Both blank and labeled COMMON are supported. EQUIVA- 
LENCE is not supported. 

n ON conditions; a mechanism for handling asynchronous 
interrupts within a BASIC program. The interrupt service 
routines are part of the program, accessible via GOTO, 
GOSUB or CALL statements. Normal program flow can be 
altered at any line boundary in response to one of these 
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interrupts. Examples of possible interrupts include 
keyboard keystrokes, interrupts from I/O devices, soft- 
ware signals, and real-time clock events. 

■ Structured programming constructs such as IF/THEN/ 
ELSE, WHILE and REPEAT loops, and CASE. 

■ A REDIM statement that can dynamically change array 
bounds. 

■ Dynamic variable allocation/deallocation via the ALLO- 
CATE and DEALLOCATE statements. 

User Code Structure 

The internal representation and management of the 
user's program in the Model 520 BASIC system provides 
insight into a complex and fascinating software architec- 
ture. This representation is called the program chain, which 
is a collection of contexts,* each of which represents a 
user-level subprogram. A context can either be compiled, 
or in a form from which the original source code can be 
reconstructed, called intermediate code (icode). Compiled 
contexts are created using the COMPILE command (not to 
be confused with the code compiled by the incremental 
run-time compiler), and are discussed in greater detail 
below. The icode contexts can be listed and modified at 
the source level by the user; the name comes from the fact 
that the source is represented internally in a form that is 
midway between source and object code. The icode con- 
texts also contain the incrementally compiled object code 
produced by the run-time compiler as the program runs. 
Intermediate Code Contexts. An intermediate code context 
consists of two machine data segments: the icode segment 
and the symbol table segment (see Fig. 1). 

The context header holds information that describes the 
context and its relationship to the other contexts in the 
program. Also in the context header is a pointer to the 
corresponding symbol table segment and to the next and 
previous contexts in the program chain. The static object 
code contains many small code sequences needed to sup- 
port running BASIC programs, including code to handle 
ON conditions, end the program, handle input responses, 
and other tasks. This static object code is always there, and 
the incrementally compiled object code branches to it when 
in need of some help for one of these tasks. 

'The reader should be aware lhat other articles in Ihis issue may deline the term "context" 
dillerently 
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Fig. 1 . The icode context contains two segments as shown. 



The formal schema area holds a compact description of 
the parameter list for this subprogram. It describes the 
number and types of the parameters and is useful for sup- 
porting the call linkages. The icode area holds the represen- 
tation of the lines of the user's subprogram. Each line of 
source corresponds to one line of icode. Whenever the user 
modifies the intermediate code, the object code gets thrown 
away. The intermediate code can then grow or shrink with- 
out having to move the object code. The incrementally 
compiled statement object code is the object code for the 
statements in the context. As the program runs, the object 
code builds up in this area. The segment is extended if 
necessary to make room for more object code. 

The free space contains all the unused space in each 
segment; all the other areas are directly adjacent. The object 
code for a keyboard command goes into this area. Since a 
command is a one-time event, and not part of the program, 
the object code for that command disappears after the com- 
mand is executed. If there is not enough empty space to 
hold the command's object code, the segment is increased 
to make room. 

The segment transfer table holds the pointers to proce- 
dures for calls into and out of a segment. During incremen- 
tal run-time compilation, this table grows and may cause 
a segment extension. 

The symbol table header contains a pointer to the icode 
segment, the total size of the symbol table segment, and 
lengths of items in the symbol table. The symbol table area 
contains a series of entries, one for each identifier in the 
context. There are fields in the entry for the storage organi- 
zation of the identifier (e.g.. COMMON and ALLOCATED), the 
identifier representation such as DOUBLE or REAL, the 
number of dimensions (if an array), the type of identifier 
(label, numeric variable, subprogram, etc.), the offset into 
the value area of its definition, and the characters of the 
identifier name. If this area has to grow because the user 
enters new identifiers, it moves the prerun object code 
down, extending the segment if necessary. 

The prerun object code allocates space for the local vari- 
ables of the context, and it also initializes any bounds that 
these variables need. This object code does not correspond 
to any program statement; it just sets up the variables that 
the statement object code will use. In BASIC, variables do 
not have to be declared explicitly; new variables can be 
defined by keyboard operations or even by modifying an 
executing program. This run-time implicit variable alloca- 
tion can cause the prerun object code to grow so that the 
new variables can be initialized at the next activation of 
this context. 

The double segment approach facilitates the manage- 
ment of all the dynamic edges. All areas except for the two 
headers must be able to grow. The icode area and the sym- 
bol table area must grow at the same time during parsing. 
The statement object code area and the prerun object code 
area must grow simultaneously during program execution. 
Compiled Code Contexts. The user can compile any context 
currently in memory by using the COMPILE command and 
store the object code in a PROG format file. Two benefits 
accrue from the fact that compiled contexts contain no 
intermediate code. They require less memory when loaded, 
and it becomes possible to release programs without releas- 
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Fig. 2. Machine data segment tor compiled code context 

ing their source. Compiled and icode contexts can coexist 
in the same program. In this case the icode subprograms 
list normally, while the compiled ones list the source of 
their original context header. These lines begin with 
»>» to indicate that the subprogram code is compiled. 

Since compiled contexts have fewer dynamic edges than 
their intermediate code counterparts, they require only one 
machine data segment (see Fig. 2). 

Icode Format. Each context contains a block of inter- 
mediate code that directly represents the source text of the 
original subprogram. There is one line of icode for each 
line in the source. A line of icode contains a header, fol- 
lowed by a series of tokens that represent keywords, 
operators, constants, and symbol table entries. These to- 
kens are of varying length and are generally in the same 
order as the elements they represent in the original source, 
except for expressions, which are in reverse Polish notation 
(RPN). The first byte of each icode token describes what 
type of entry it is and how many bytes the entry takes. 

The combination of RPN for expressions and source order 
for everything else in the intermediate code may seem 
strange. Since the Model 520*8 CPU uses a stack architec- 
ture, RPN makes it easy for the compiler to generate optimal 
code for expressions. On the other hand, source order 
simplifies listing and nonexpression code generation, be- 
cause the compiler can know what kind of statement it is 
dealing with at the beginning of the icode line. 

A line of icode is simply a series of bytes from 11 to 255 
bytes long. There are length fields in each line to allow the 
system to traverse the lines of icode either forwards or 
backwards. This last capability is useful when scrolling 
backwards in the editor. The system generally refers to a 
line of icode by specifying its offset in the icode area. 

The objective in the design of the intermediate code was 
to minimize the memory space it requires. Most program 
elements need just a single-byte entry to represent them. 
For numeric: constants, studies have shown that most con- 
stants are small integers. Thus, for integer constants in the 
range 0 to 9, single-byte icode entries are used. For the 
somewhat larger constants (up to 255), two-byte entries are 
used. Constants greater than 255 require five-byte entries. 
Floating-point constants are represented as character 
strings. Most real constants such as 5.3 only have a few 



characters, so storing them as characters takes fewer bytes 
of storage than if they were stored as an eight-byte real 
value. Keywords are arranged so that the most common 
ones have a single-byte icode representation. All other en- 
tries take either two or three bytes. 

Symbol table entires have two possible forms. In BASIC 
programs, commonly referenced identifiers tend to have 
single-letter names such as I. J. and N, and represent 
numeric variables. Ten special locations are reserved in 
the symbol table for this type of identifier, and a special 
single-byte icode entry exists to represent them. All other 
identifiers need a two-byte icode entry. If there are more 
than ten single-character numeric variables, the first ten 
will use the single-byte representation, and the rest will 
use the two-byte representation. All nonnumeric iden- 
tifiers, such as strings, labels, functions, and subprograms 
always use a two-byte icode representation. 

Two examples of icode program lines for two typical 
BASIC statements are shown in Fig. 3. 

Fundamental Mechanisms 

The run-time compiler is an incremental compiler. That 
is, the program is compiled one piece at a lime. In this case 
the unit of compilation is a BASIC program line and each 
line is compiled the first time it is executed. The simple 
program listed in Fig. 4a illustrates the fundamental 
mechanisms of the run-time compiler. As a programmer 
enters a program, it is translated from the BASIC source 
code to an intermediate code representation as discussed 
earlier. When the programmer presses the RUN key to exe- 
cute the program, the system detects that the first line of 
the program is not yet compiled, so a bootstrap code se- 
quence is emitted to invoke the compiler to compile the 
first line (Fig. 4b) and control is passed to it. Line 10 is 
then compiled and the compiler checks to see if the next 
line, line 20, has been compiled yet. It has not, so a code 
sequence to invoke the compiler for line 20 is appended 
to the end of the code for line 10. 

This new code overlays the initial bootstrap sequence, 
which is no longer needed (Fig. 4c), and control is trans- 
ferred to the code for line 10, which is executed and then 

Original BASIC Una: 

1000 PRINT REVS<ASaB»J,A-PI 



PRINT 



0 3 232 0 22 17 10 0 0 0 232 0 25 

1000 | Un I A* 
SiMus Col 
Pol 

Prior Ocode 
Lan Ottaet 

funcompiladl 



0 28 160 24« 16 170 MO 180 161 
at a REVSO . A PI • 



Original BASIC Una: 
1010 Finlnh: END 
Icoda: 



ond 



0 3 242 32 21 22 IS 0 19 24 0 31 
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Stalua 
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/ \/ 
Flnlah 
llabal) 
Ocoda 
Onaet 
(complied) 



246 105 254 7 22 32 101 110 100 
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Un I 
Col 

Commanl Poi 
Header 



Fig. 3. Two examples ot icode representations ot BASIC 
program lines. 
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(a) Example BASIC program 

10 PRINT "Table of Squares and Square Roots" 
20 1-1 

30 IF I 100 THEN Done 
40 PRINT M A 2.SQR{I) 
50 I = 1+1 
60 GOTO 30 
70 DoneiEND 

(b) run command bootstraps to begin execution 



call compiler) 10) 



(c) Line 10 compiled 



code (or line 10 
call compller(20) 



(d) Line 10 executed and line 20 compiled 



code (or line 10 
code (or line 20 
'call compiler(30) 



(e) Line 20 executed and line 30 compiled 



code (or 

code (or line 20 

code (or line 30 
test (or I 100 
true: call compiler(70) 
(alse: call compller(40) 



(f) Line 30 executed (test was (alse) and line 40 compiled 



code (or line 1 
code (or line 20 
code (or line 30 
lest for I too 
true: call compller(70) 
(alse: code (or line 40 
call compiler(SO) 



follows through to invoke the compiler for line 20. Simi- 
larly, line 20 is compiled (Fig. 4d) and executed and the 
compiler is called to compile line 30. After line 30 is exe- 
cuted, there are two different lines that may be executed 
next, depending on the results of the IF test. Therefore, the 
compiler emits code to invoke itself for both lines 40 and 
70, and the IF test will branch to one piece of code or the 
other (Fig. 4e). Because the initial value of I is 1, the test 
is false the first time line 30 is executed, so the compiler 
is called to compile line 40. Lines 40 and 50 are compiled 
and executed (Figs. 4f and 4g) and the compiler is then 
invoked to compile line 60. 

Line 60 is an unconditional transfer of control to line 
30, which the compiler realizes is already compiled. There- 
fore, a branch instruction to the code for line 30 is all that 
is emitted for line 60 (Fig. 4h). The main loop in the program 
is now entirely compiled, so the next 99 times through the 
loop execute only compiled code, allowing the perfor- 
mance of the system to be essentially the same as the per- 
formance of a traditional compiled system. 

Once the value of I reaches 101, the test in line 30 is 
true, causing the compiler to be invoked to compile line 
70. In this case, the code for line 70 cannot directly overlay 
the call to the compiler, because doing so would overlay 
code for other program lines. Instead, the code of line 70 
is appended to the end of the rest of the compiled code 
and the call to the compiler for line 70 is replaced with a 
branch instruction to the code for line 70 (Fig. 4i). The 
program then terminates, but the compiled code is still 
present. If the user chooses to rerun the program, the RUN 
command now finds that the first line is already compiled 
and transfers control directly to it so that the second execu- 
tion of the program executes only compiled code. 



(g) Line 40 executed and line 50 compiled 



code (or line 10 

code (or line 20 

code (or line 30 
test (or I 100 
true: call compiler(70) 
(alse: code (or line 40 

code (or line 50 

call compiler(60) 



(h) Line 50 executed and line 60 compiled 



code (or I 
code for line 20 
code for line 30 
test for I 100 
true: call compller(70) 
false: code for line 40 
code for line 50 
branch to code for line 30 



(i) Line 30 executed (test was true) and line 70 compiled 



code for line 10 
code for line 20 
code for line 30 
test for I 100 

true: branch to code tor line 70 

false: code for line 40 
code for line 50 
branch to code for line 30 
code tor line 70 
end program 



Fig. 4. Example ot run-time compiling. See text lor explanation. 



Interactive Features 

In traditional interpretive systems, special checks for 
user interactions or tracing take place at the beginning of 
each line. Checking one or more flags can be done with 
just a few machine instructions, which require a very small 
overhead compared to the overall execution of the interpre- 
ter. In a compiled environment even a few instructions can 
consume a large percentage of the total execution lime of 
the program. The solution developed in cooperation with 
the CPU microcode team was the start-of-line-check in- 
struction SOLC. This instruction is the first instruction of 
every compiled BASIC line. It performs two important 
tasks. One, it checks a word at the base of the stack for 
zero versus nonzero. If one or more bits in the word have 
been set, indicating that something special needs to occur, 
a trap occurs and the system takes the appropriate action. 
If the word is zero, execution proceeds to the next instruc- 
tion. Second, the SOLC instruction writes its own address 
at a fixed location in the stack so that the system can always 
find out which line is being executed. 

A traditional interactive feature on HP desktop comput- 
ers has been the live keyboard. The user can evaluate ex- 
pressions, examine and modify program variables, and exe- 
cute BASIC statements from the keyboard while the pro- 
gram is running. When a Model 520 user presses the EXE- 
CUTE key after typing in a command, one of the bits in the 
SOLC check word is set, causing a trap to occur at the next 
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SOLC instruction. The system then parses, compiles, and 
executes the interactive command before returning control 
to the program line that was interrupted. 

Another traditional HP interactive debugging feature is 
the ability to trace program flow by enabling the TRACE 
mode. This causes a message to be displayed on each nonse- 
quential transfer of control, showing the source and desti- 
nation line numbers. When a Model 520 programmer ena- 
bles tracing, another bit in the SOLC check word is set 
which causes a trap on every SOLC instruction. The system 
can then determine whether or not the BASIC line cur- 
rently being executed is immediately after the previously 
executed line, and display an appropriate message if it 
is not. 

Another important debugging capability is the ability to 
trace the assignments to program variables. When the pro- 
grammer enables variable tracing, the system enters a mode 
where a trap occurs on every store into a memory location. 
The system can then determine if the location is the loca- 
tion of a program variable, and if so, display a message 
with the new value of the variable and the line number of 
the line that changed the variable. 

Although enabling either or both of the tracing modes 
slows down program execution speed significantly, the 
program usually executes faster than the programmer can 
follow it unless the trace messages are slowed down with 
the TRACE WAIT statement, which causes a delay after every 
trace message is displayed. 

The occurrence of an asynchronous ON condition also 
causes a bit to be set in the SOLC check word. When the 
next SOLC instruction executes, a trap occurs and the sys- 
tem sets up a branch to the specified service routine if the 
scope and priority conditions are satisfied. The system 
transfers control to a piece of static object code at the begin- 
ning of a context, which in turn branches to the service 
routine if it is already compiled, or to a bootstrap sequence 
to invoke the compiler if it is not yet compiled. CALL or 
GOSUB branches invoked by the ON condition return to the 
point of interruption as directed by the static object code 
after handling the ON condition. 

Program Modification and Continuation 

While debugging a program, a programmer often wants 
to be able to make a fix to the program and resume execution 
without having to start the program over. The run-time 
compiler allows the Model 520 Computer to support this 
capability with a compiled system. As an example, suppose 
the author of the program in Fig. 4a decided during the 
execution of the program to calculate the squares and 
square roots for all integers up to 1000 instead of 100 as 
in the original program. Suppose that the program was at 
line 40 when the programmer entered the editor and 
changed line 30 (Fig. 5a). The compiled code for the pro- 
gram is no longer valid, so it is thrown away. The system 
remembers that the program is currently at line 40. When 
the programmer continues the program, the system deter- 
mines that line 40 is not compiled and sets up a bootstrap 
sequence for line 40 similar to the way in which the pro- 
gram first began execution with line 10 (Fig. 5b). Line 40 
is recompiled and executed, followed by line 50 and so 
forth (Figs. 5c to 5g). The compiled code is rebuilt a line 
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at a time, just as it was constructed the first time. 

There are some restrictions on what lines can be changed 
while a program is running. Lines that have only partially 
been executed cannot be modified or deleted. For example, 
a line that invokes a multiline function or a subprogram 
cannot be changed, or the function or subprogram would 
lose the place it should return to. The SUB statement that 
defines an active subprogram cannot be modified or deleted 
until that subprogram returns to its caller. A similar restric- 
tion holds for variable allocation statements such as DIM 
and COMMON statements in an active subprogram. These 
lines that cannot be changed are called busy lines. 

Even though a busy line cannot be changed, the compiled 
code for it may still be invalidated by an allowed change 
to the context containing the line. In the case of a line that 
invoked a multiline function, it must be recompiled when 
the function returns. It is clearly undesirable to have to 
check on every return from a function or subprogram to 
see if the return point is still compiled. Instead, when com- 
piled code for a busy line is discarded, the return address 
in the execution stack is patched to point at an entry point 



(a) Example BASIC program 

10 PRINT "Table of Squares and Square Roots" 
20 I = 1 

30 IF I 1000 THEN Done 
40 PRINT I.|a2.SOR(I) 
50 I = 1+1 
60 GOTO 30 
70 Done END 

(b) continue command bootstraps to resume execution 



call compiler(40) 



(c) Line 40 compiled 



code for line 40 
call compiler(SO) 



(d) Line 40 executed and line 50 recompiled 



code for line 40 
code for line 50 
call compller(60) 



(e) Line 50 executed and line 60 recompiled 



code for line 40 




code for line 50 




code for llne{30) 





(f) Line 30 recompiled 



code for line 40 
code for line 50 
code for line 30 
test for I 1000 

true: call compller(70) 

false: branch to code for line 40 



(g) Line 30 executed (test was true) and line 70 compiled 



code for line 40 
code for line 50 
code for line 30 

lest tor I 1000 ^ 
true: branch to code for line 70 
false: branch to code for line 40 
code for line 70 
end program 



Fig. 5. Effect of interactive program modification on run-time 
compilation process. See text for explanation. 
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An important consideration throughout the design of BASIC 
tor the HP 9000 Model 520 Computer was upward compatibility 
with BASIC tor the HP 9845 and HP 9000 Series 200 Computers 
Even though the Series 200 appeared more than a year betore 
the Model 520. the two BASIC language systems were designed 
concurrently. A compatibility committee composed of members 
from both design teams coordinated the two efforts. As a result, 
Model 520 BASIC is a nearly pure superset of Series 200 BASIC 
Thus, almost any Series 200 program can run without modification 
on the Model 520. The most significant change is usually for 
device select codes. The relationship between HP 9845 and 
Model 520 BASIC is more complex. Some features of the lan- 
guage were redefined to improve the consistency of the language 
and to pave the way for future development. The most significant 
changes are in the I/O and graphics sublanguages. Since not 
all HP 9845 programs can run on a Model 520 Computer without 
modification, a translator program was written to assist users in 
porting valuable existing software to the Model 520. 

Experience to date with transporting HP 9835 and HP 9845 
programs to the Model 520 has been quite good Many programs 
execute successfully without modification, and most will execute 
correctly after manual modification of a few syntactically invalid 
lines In spite of the success rate of porting programs without 
the translator, use of the translator program is recommended as 
insurance against some subtle semantic changes There is a 
small set of programs that do require great effort to port. These 
programs contain a significant number of device-dependent por- 
tions or portions written In assembly language. Included in the 
device-dependent set are programs that depend heavily on di- 
rectly addressing the CRT display and on certain uses of its 
video enhancement options. 

There are three basic difference categories that the translator 
program handles. First is where the Model 520 supports identical 
semantics, but by way of a different syntax. Second is where the 
Model 520 supports the same syntax, but assigns different 
semantics to it. Third is neither of the above. Elements of this 
last set range from a slight change in semantics, which may 
affect program behavior only very infrequently, to features that 
have no equivalent and require user understanding of the intent 
of the program to make the changes. The translator recognizes 
almost all of these, flags them, and gives suggestions on how 
to translate manually. 

The best example of first category is the modulo operator mod, 
which has been changed to modulo in the Model 520. Some 
others can result in a single line expanding to multiple lines (see 
mat input example below), but the semantics are still preserved. 

The most pervasive example of the second category is the 
change from BCD to binary arithmetic In Ihis case the translator 
issues diagnostics when it sees potential problems such as 
noninteger numbers in FOR loop bounds and step sizes, or rela- 
tional equality tests where exact equality was possible with BCD 
values, but will not be with binary values. A second example is 
the change in precedence for some operators For example, the 
NOT operator has lower precedence on the Model 520 than on 
the HP 9835 and HP 9845 Computers. 

Translation Examples 

In many cases, the changed precedence does not affect the 
results of computations. For example, the expression -a*b 
means (-A)* B on the HP 9835 and HP 9845, but it means -|A ■ B) 
on the Model 520 Either interpretation of the expression pro- 
duces the same answer (with the rare exception of an overflow 
in an intermediate result). There are cases, though, where the 



changed precedence does matter The expression -3 mod 2 
yields a value of one on the HP 9835 and HP 9845 because it 
is (-3) MOD 2 The expression -3 modulo 2 yields a value of - 1 
on the Model 520, because it is interpreted - (3 MODULO 2). After 
passing through the translator, the HP 9835 and HP 9845 expres- 
sions appear as (-A)* B and (-3) modulo 2. The -A is paren- 
thesized unnecessarily, because of simplifying assumptions in 
the expression parser. These simplifying assumptions are con- 
servative — they may cause unnecessary parenthesization, but 
will not omit any necessary parentheses. 

When the translator encounters the statement 

20 FOR 1=1 TO 2 STEP .1 

it gives the warning 

FOR loop with non-integer bounds or slep size may behave differently due 
to binary arithmetic 

Most of the items handled by the translator could be done 
manually, Ihough at the cost of considerable tedium. For exam- 
ple, inputting an array can be done on the HP 9845 by the 
statement 

100 MAT INPUT A 

The identical operation on a the Model 520 is accomplished by 

100 INPUT A(.) 

The HP 9845 also allows the redimensioning of an array by an 
INPUT statement, but the Model 520 does not. The statement 

100 MAT INPUT A(3,5) 

translates to 

100 REDIM AI3.5) 

101 INPUT A(-) 

Finally, consider an extreme case where the HP 9845 statement 

100 IF X>3 THEN MAT INPUT A( N DIV M. N MOD M) 

is converted automatically by the translator to 

100 IF X>3 THEN 

101 REDIM A((-N) DIV M,(-N) MODULO M| 

102 INPUT A(.) 

103 END IF 

If adding new lines creates duplicate line numbers in the pro- 
gram source, the translator issues a diagnostic, and correction 
of the problem will require user intervention after getting the 
translated source. No attempt is made to renumber existing 
source lines, since that would also require finding and changing 
any programming references to Ihe affected line numbers. 

One of the most complicated translation examples can be 
found in the CAT statement. The HP 9845 statement 

100 CAT TO A$(-),Skip,N;"selector:msus",1 

translates to 

1 00 CAT":msus" TO ASH; SELECT "selector ".SKIP Skip.COUNT N.NOHEADER 

Note lhat every parameter after A$(*) in the original statemenl is 
optional. Furthermore, with the exception of the final portion (.1), 
each parameter is independent of all the others, and in the string 
seiectonmsus, either the selector or the :msus portion could appear 
without the other In all cases the associated parameter in the 
translation is left out or included as necessary. The final ,1 is 
what causes the noheader portion to appear in the translation. 
If this portion is .0, the noheader portion does not appear If the 
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final portion is a variable, a diagnostic is given lo the user to 
check the statement tor possible manual changes- 
Implementation 

The translator implementation draws much from conventional 
compiler technology It is driven by a recursive descent parser, 
which in turn relies on a scanner to build language tokens by 
reading the input statement one charade* at a time. At first 
glance, it appears that the translator would require complete 
knowledge of the HP 9835 and HP 9845 BASIC language gram- 
mar Arithmetic expressions can occur in all sorts of strange 
places m BASIC statements, and every one of them must be 
inspected for possible changes 

The most significant simplifying assumption is that each input 
program is a syntactically valid HP 9845 program as SAVEd by 
the HP 9845 s interpreter. Thus, many statements may be trans- 
lated with no knowledge of their grammar Each BASIC statement 
is treated as a sequence of expressions (usually delimited by a 
blank or a comma) which can generally be inspected and trans- 
lated independently This means that isolated keywords are pro- 
cessed as an expression by themselves. Complex expressions 
may cause recursive calls on ihe expression evaluator to evaluate 
subexpressions such as parenthesized expressions, function or 
procedure parameters, etc. 

Of course, things are not quite that simple everywhere Some 
statements must be understood in greater detail. They are han- 
dled in typical (nonlable-driven) recursive descent fashion. When 
a keyword or expression type is detected at any level that requires 
more detailed analysis, a handling procedure is called, which 



in the static object code for the context that will set up the 
compiler to recompile the busy line and resume execution 
at the appropriate place in it. 

Summary 

Model 520 BASIC has the interactive friendliness of pre- 
vious interpretive systems with the execution performance 
of a compiler. All of the interactive features of BASIC in 
HP's earlier desktop systems are supported. 

The extra overhead introduced by run-time compiling 
accounts for less than 5% of the execution time of most 
programs and it is less than 1% for many of them. The 
compiling that takes place at run time is very fast since 
syntax is checked as lines are entered and the intermediate 
code produced is optimized for compiling. 

For large programs, the intermediate code and object 
code are each about the same size as the source. (This does 
not include run-time support routines which are consid- 
ered part of the system.) Because of the ability to throw 
away code when no more memory is available, a program 
can run (slowly) in just slightly more memory than is re- 
quired for the intermediate code and variables. Further- 
more, the system provides the ability to produce and exe- 
cute compiled code without any associated intermediate 
code by using the COMPILE command. 
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may itself invoke the expression evaluator to handle the subex- 
pressions To support this detection and subsequent handling, 
ihe expression evaluator always returns the type of the expression 
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A Local Area Network for the HP 9000 
Series 500 Computers 

by John J. Balza, H. Michael Wenzel, and James L. Willits 



HEWLETT-PACKARD'S Manufacturer's Productivity 
Network (MPN) divides the computing applications 
for a typical manufacturing company into four areas: 
accounting, manufacturing, factory control, and computer- 
aided design. Data is collected and stored in each area and 
access is provided to users via combinations of computing 
and networking. Data access by users in the same area is 
required frequently and to other areas more intermittently. 

In the computer-aided design area, scientific and en- 
gineering workstations are connected into clusters for re- 
source and information sharing. LAN 9000 provides the 
capability to cluster HP 9000 Series 500 Computers on a 
local area network. In the future, additional HP-UX* work- 
stations such as the HP 9000 Series 200 Computers will 
also be connected to this local area network. 

Communication between the four MPN areas occurs over 
a backbone network. The backbone may consist of various 
forms of communication technology such as a local area 
network, packet switching, and private branch exchange. 
LAN 9000 can also serve as a backbone network connecting 
HP computers from the other three MPN areas. 

Definition of LAN 9000 

LAN 9000 is a product composed of both hardware and 
software. Its structure follows the ISO (International Stan- 
dards Organization) OSI (open system interconnect) model,' 
which divides network functionality into seven layers (see 
Fig. 1). In the LAN 9000 implementation, the physical and 
link layers are accomplished in hardware, and the remain- 
ing upper layers are implemented in HP 9000 software. 
The physical layer provides access to the physical com- 
munications media. The link layer defines the frame format 

•HP-UX is HP's implementation ol the UNIX " operating system 
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and the protocol for error detection. The internet layer 
provides the protocol for connecting multiple networks, 
multiplexing, and data segmentation and reassembly. The 
transport layer provides end-to-end reliability, multiplex- 
ing and flow control. The session layer provides a common 
interface to the transport for the applications. The presen- 
tation and application layers provide data translation and 
the actual network services visible to the user. 
Hardware. The LAN 9000 hardware implements the phys- 
ical and link layers for the Ethernet local area network 
specification. 2 " 1 The hardware consists of an HP-IB (IEEE 
488) interface card connected to an Ethernet interface unit, 
which in turn is connected by twisted-pair branch cable 
to the transceiver that taps the 50-ohm Ethernet coax cable 
(see Fig. 2). Ethernet is a bus configuration where conten- 
tion between multiple stations is resolved by a technique 
called carrier-sense multiple-access and collision detect 
(CSMA/CD). The transceiver provides the driver electronics 
for the cable, and the Ethernet interface unit provides ad- 
dress recognition, arbitration, and error detection. The 
Ethernet specification supports lOM-bit/s performance for 
up to 100 nodes on a 500-meter segment of Ethernet coax. 
Each branch cable can be up to 50 meters long. 
Software. The LAN 9000 software consists of the upper 
layers of protocol and a supporting network architecture 
(see Fig. 1), which will be discussed later. The transport 
and internet levels were originally defined by the U.S. Defense 
Advanced Research Projects Administration (DARPA) 4,5 
and are currently used in a large functional network called 
ARPANET.* The transport layer is called the transmission 
control protocol (TCP) and the internet layer is called the 
internet protocol (IP). The applications consist primarily 
of three functions: the ability to access remote files, the 

•The LAN 9000 implementation is a subsel ol the DARPA protocols and has not been 
tested lor use on ARPANET 
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ability to achieve high-speed transfer of files, and a lower- 
level tool that enables users to initiate and communicate 
with remote processes programmatically. 

Accessing remote data is accomplished both by remote 
file access (RFA) and network file transfer (NTT). RFA is 
advantageous when accessing individual remote records 
and when using existing programs that access files. The 
method of access for RFA is a simple extension of the file 
path name with a remote specifier. For example, the differ- 
ence in HP-UX commands between editing a local file and 
a remote file on node george is: 

Local: vi textfile 

Remote: vi net george textfile 

NFT is advantageous when the high-speed movement of 
a file from one system to another is desired. After transfer, 
the new file can be accessed for processing. NFT achieves 
about four times the throughput of RFA by using large 
blocks and a pipelined transfer technique. The topology 
for NFT is the three-node model, where the initiator, pro- 
ducer, and consumer can all be on different nodes. NFT is 
accomplished with the dscopy command, which includes 
the source and destination file path names as parameters. 
File security is invoked for both RFA and NFT by the system 
containing the file. Security is applied to remote access 
consistent with the mechanisms used for local access. 

Interprocess communication (IPC) and remote process 
management (RPM) are lower-level tools that enable a user 
to write custom distributed applications. They consist of 
a number of procedures that can be called from the user 
program. RPM gives the program the ability to create and 
execute another program on a remote system and to termi- 
nate it. IPC consists of procedures to establish a communi- 
cation path, read and write data, and terminate the path. 
The communication path is called a virtual circuit and 
enables full-duplex communication between both process- 
es. The rendezvous between the two processes is achieved 
through a name assignment by one process, a name lookup 
by the other process, and then a handshake to establish 
the virtual circuit. The IPC functionality was modeled after 
the IPC specified in the 4.2BSD version of UNIX" de- 
veloped by the University of California at Berkeley (UCB). 

Design of LAN 9000 

Early in the project we knew that there would be several 
major problems to be solved. It was our intention to select 
an architecture so that as our networking needs changed, 
the architecture would still support them. Several key prob- 
lems were recognized. First, we knew that we would be 

UNIX is a U S iradema'k ol Bell Laboratories 




'Network Code 

Fig. 3. Layered isolation ol portable network code 

dealing with several operating systems as well as several 
processor families. At the time we were considering at least 
two different operating systems and processors, one of 
which was the NMOS-BI VLSI 32-bit system used in the 
HP 9000 Series 500 Computers. We wanted to build soft- 
ware that could be used in any multitasking operating sys- 
tem with any processor family. 

Second, we knew from experience that many protocols 
would need to be implemented within this architecture. 
While there are some industry standard protocols today, 
work in this area is just beginning. To meet HP customer 
needs in the future, we would have to support a variety 
of protocols at each of the seven levels of the OSI model. 
Even if we only implemented industry or international 
standards, there would still be a multitude of protocols, 
because many different physical configurations could be 
used to construct a network. While our initial product was 
only for local area networks, eventually we would need 
remote connections and connections over public data 
networks. 

Third, the system had to be robust and integrated. There 
were several computer scientists working on the original 
product and over time many more would contribute to the 
networking functionality. We needed to define an environ- 
ment where these designers could work independently and 
still have the result appear to be one integrated product 
that would be free of errors. 

Because of these challenges, our first task was to define 
what we eventually called our data communications im- 
plementation architecture. This architecture is a com- 
prehensive specification of module interfaces. As shown 
in Fig. 3. these modules are successively layered in their 
isolation from the host operating system. For efficiency 
and portability, the network protocol modules assume a 
very high-level execution environment that is tuned for 
networking code. Similarly, the execution environment 

(continued on page 25) 
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Data Communications for a 32-Bit Computer Workstation 



by Vincent C. Jones 



The HP 9000 Series 500 Computers place heavy demands on 
data communications Aside from the local networking capability 
provided by LAN 9000. there are numerous other needs, because 
the real world does not consist exclusively of HP computers 
running HP networking software. The range of these needs is 
even wider than normal, because of the pivotal nature of the 
Series 500 itself It needs not only the communications capability 
of a single-user workstation, but also those of a powerful multiuser 
machine. 

Single-user workstations, even those as powerful as the desk- 
top version of the Series 500, the Model 520, do not function in 
isolation. Effective problem solving often requires synergy be- 
tween mainframe resources and the individual workstations. This 
requires easy communication between workstation and main- 
frame, particularly interactive terminal-oriented access and reli- 
able file transfer A typical application might require the Model 
520 to offload some computation-intensive tasks from a main- 
frame, allowing the mainframe to provide better response to a 
larger number of users. 

In multiuser mode, the emphasis tends to be more along the 
line of resource sharing among the different users, The communi- 
cation link with other mainframes is a resource to be shared the 
same as a line printer or data base The interactive linkup from 
the user's terminal to multiple mainframes is not as important a 
need as the ability lo get required data to the user's local main- 
frame for processing, to communicate with users on other main- 
frames, or to move programs and data to larger, more specialized 
mainframes for processing 

A second dimension to the matrix of data communications 
needs is the network environment in which the mainframes oper- 
ate SNA (systems network architecture) and bisync are common 
with IBM host computers while DecNet'" and UNIX'" predomi- 
nate on host computers made by Digital Equipment Corporation 
(DEC) HP's DSN services are similarly tuned to take advantage 
of the strengths of HP computers, while Burroughs, Univac, and 
just about every other computer vendor offer their own networking 
solutions Unfortunately, they are all incompatible, making it 
necessary to implement a number of solutions while remaining 
hopelessly incomplete. However, IBM is such a dominant force 
in the mainframe market that virtually all vendors offer connection 
to IBM using emulation techniques. Indeed. IBM 2780/3780 RJE 
(remote pb entry) has become so prevalent among minicomputer 
vendors that it is considered a de laclo communications standard 
for reliable file transfer even in non-IBM environments. Similarly, 
almost everyone allows effective on-line access from "dumb" 
asynchronous ASCII terminals. 

This lets us define a minimal set of communications abilities 
to allow efficient use of the Series 500 in most computing environ- 
ments Returning to the fundamental needs of users, we need 
interactive mainframe access and reliable file transfer. An asyn- 
chronous ASCII terminal emulation with programmable data rate, 
character size, parity, stop bits, end-of-line, start-of-line, prompt, 
and other parameters can be configured to access virtually any 
computer that can connect to ASCII terminals By making the 
emulator user-modifiable (by providing source code or other 
techniques), access can be gained to any host that supports 
asynchronous terminals Adding the capability to divert host 
transmission to a file and use file input in place of keystrokes 

UNIX H a US trademark or Bell Laboratories 

DecNet <s a U S trademark ot Digital Equipment Corporation 



provides a simple, low-cost file transfer capability Where higher 
data integrity is required, IBM 2780 RJE provides a synchronous, 
error-controlled linking. 

This leaves only interactive IBM access to provide, more com- 
monly known as 3270 capability Asynchronous terminal emula- 
tion can be used with black boxes known as protocol converters, 
but typically these are useful only under limited conditions Most 
important, they are not a one-for-one replacement for an IBM 
3270 display station, which requires users to memorize multi- 
stroke key sequences to access the myriad key functions avail- 
able on actual 3270 systems. However, where limited or occa- 
sional access is required, especially if the user is also no longer 
using "the real thing," they can function quite well. 

Unfortunately, IBM 3270 does not specify a unique access 
means. Instead, it is an entire family of products including cluster 
controllers, display stations, printers and integrated controller/ 
display stations For example, to meet varied customer needs 
and keep up with technology advances, there are over twenty 
different models of 3274 controllers (some are obsolete) There 
are more than ten different models of 3278 and 3279 display 
stations, any of which can be used with current 3274 controllers. 
Despite the plethora of options, however, there are really only 
two approaches to 3270 emulation. The first (and until late 1982. 
the only approach) is to emulate Ihe entire cluster controller and 
attached display stations using bisync or SNA protocols to con- 
nect to the mainframe via a 370x front end. Commonly called 
3274 emulation, this approach is particularly attractive for mul- 
tiuser situations, where up to 32 users can simultaneously access 
the mainframe through Ihe emulator while requiring only a single 
link from the local computer lo the IBM mainframe. 

The second approach, pioneered on the IBM Personal Com- 
puter by Technical Analysis Corporation (now Digital Communi- 
cations Associates, Inc.). is to emulate only the display station, 
leaving the existing IBM cluster controller in place and hooking 
into the coax protocol used between controller and display sta- 
tions. Commonly called 3278 emulation, this approach is most 
attractive when replacing individual display stations with com- 
puter workstations. Either approach, however, can typically be 
used m Ihe majority of applications, albeit not always optimally. 
This means lhat Ihe critical interconnection needs of most work- 
station users can be met with just three networking products: 
flexible asynchronous terminal emulation, simple IBM 2780/3780 
remote job entry emulation, and some form of IBM 3270 capability. 

In addition to these minimal requirements, other communica- 
tion needs are common enough to demand specific resolution, 
particularly for efficient integration into HP, DEC. and UNIX envi- 
ronments as well as IBM. 

Implementations 

There are probably as many ways to develop the required 
capabilities as there are opinions in what makes up an adequate 
set of capabilities. We had choices ranging from "offer what's 
already available off the shelf" to "design, develop and build 
from scratch " As will be seen, we tried to select whatever would 
provide a quality product in the shortest time — typically taking 
an existing product and modifying it as required 

The first communications products developed for the Series 
500 were two general-purpose asynchronous terminal emulators 
with file transfer capabilities — one for BASIC and one for HP-UX. 
Crucial to both was providing enough flexibility to communicate 
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with virtually any computer lhat uses ASCII characters on an 
asynchronous line This means not only supporting standard op- 
tions like line rates from 50 to 19.200 bits per second. 7-bit or 
8-bit characters, and various pannes, but also allowing options 
like defining what characters to use tor new line and XON XOFF 
host prompts before transmitting the next line, and iine-onented 
mooes complete with stan-of-iine and end-of-ime sequences 
Also required was the ability to function with existing protoco 
converters for IBM 3270 and RJE 

The BASIC asynchronous terminal emulator is based on the 
HP 9845 Computer's high-speed terminal emulator, maintaining 
the same human interface so that users moving up from the HP 
9845 would not have to learn a new emulator The HP-UX asyn- 
chronous terminal emulator (atemi) is just the opposite, a new 
design from the bottom up. At the moment . the implementation 
is only part of the total design Several critical features allowing 
modular extensions and user customization cannot be im- 
plemented until enhancements to HP-UX that will permit one 
process to reliably react to two concurrent asynchronous inputs 
are in place. 

Once we were confidenl our minimal needs were covered, we 
could start looking at how to provide more specific connections 
Primary criteria were timeliness of the implementation and utility 
lo Ihe user This led to three main communications Ihrusts: HP 
connection via Ethernet, IBM connection via RJE. and UNIX con- 
nechon via cu (call UNIX) and uucp (UNIX-lo-UNIX copy). 

As mentioned earlier. IBM communications consist of two major 
capabilities: 3270 interactive access and remote job entry While 
efforts are underway lo provide built-in 3270 capability, our initial 
effort went into file Iransler via RJE At the beginning of the 
project, we had to select from a number of potential options. For 
example, did we want to do just 2780/3780 RJE or did we want 
lo take advantage of the mulliuser capabilities of the HP 9000 
Series 500 Computers and provide multileaving RJE (MRJE)? Bell 
Laboratories' System III UNIX, which we were building on, had 
an MRJE capability (the send command) However, thai capability 
was built using a virtual protocol machine running on Ihe DEC 
KMC-1 1 communications card In addition, the System III pack- 
age was based on the assumption lhat ihe only use for RJE 
would be lo submit |ob streams lo IBM and Univac hosts, an 
unacceptable restriction in view of our desire to use RJE also lo 
exchange files with minicomputers. 

Our solution was to try to take the best of both approaches; 
keeping the convenient |Ob submittal facility of Ihe System III 
MRJE user interface (the send command), but putting it atop a 
2780/3780 RJE program (r2780) which could also be used di- 
rectly by the user if only file transfer were required Also required 
were two utility programs a trace filter to convert card trace data 
from the compressed binary form generated on-line to a readable 
listing, and a print output filter to expand IBM carriage controls 
lo HP-UX compatible sequences The HP-UX standard definition 
for send is llnk-mdependeni so lhat although the current Series 
500 implementation is 2780/3780-link-based, future enhance- 
ments such as MRJE or SNA links to IBM could be added without 
affecting the user interface 

Third on our list of required connections, after HP and IBM, is 



DEC Interactive access is fairly easy on multiuser systems — the 
aierm asychronous terminal emulator can be made totally trans- 
parent, allowing the user io take advantage of the ANSI compati- 
bility mode offered on several HP terminals The Model 520 work- 
station user is restncted. however, to "dump terminal" only While 
we consider the restnction undesirable, we do not envision many 
users interested m dedicating a 32-bit workstation to terminal 
emulation tor data entry and editing Similarly, it would be nice 
lo hook into DecNet tor file access and data transfer, but again 
priorities have prevented immediate satisfaction For now. RJE 
suffices for reliable file transfer, even though it requires a second 
terminal connection to the DEC machine to control that end of 
the connection 

Last on our list of required connections is UNIX Since HP-UX 
is based on UNIX, we felt it vital that we fit into the UNIX data 
communications environment To simplify retaining compatibility 
with evolving releases from both Bell Laboratories and the Univer- 
sity of California at Berkeley, we attempted to take the standard 
System III UNIX-to-UNIX utilities and change them as little as 
possible. We started out with cu. uucp. and uux (UNIX-to-UNIX 
execute). Although our goal was to leave them intact, we dis- 
covered significant design changes were required Most critical, 
other than fixing numerous bugs, was removing restrictions 
based on the Bell assumption that all users would have source 
code to modify Because HP-UX does not include an AT&T source 
license, features requiring modification of the source code are 
not acceptable unless that source code can be provided to the 
user by HP (i e . was designed and written by HP, not Bell Labs) 
Since all these utilities are based on asynchronous dial-up links, 
smart modems are normally used Unfortunately, each modem 
manufacturer seems to use a different protocol to tell its modem 
how to dial a specific phone number. Our solution was to move 
dialing out of the main program and put it into a separate program 
module, which is called from the mam program and written by 
Ihe user (no source license required) Sample programs showing 
how lo dial Ven Tel and Racal Vadic modems are supplied 
Similarly, in uux the list of programs that can be run from a remote 
machine was moved from a data array inside the program to an 
external file Visible changes from the System III version were 
minimized By retaining the original functionality and interface, 
standard UNIX utilities that use uucp still work as expected, includ- 
ing remote mail and the notes network 
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modules build on other environment modules and rely on 
the services of the host system interface, which provides a 
machine-independent operating system interface. The host 
system interface code consists of small and partially port- 
able modules that perform whatever actions are necessary 
to adapt the host machine's operating system for network 
use. For the Series 500 operating system, called SUN (see 



articles on pages 28, 34, and 38), many of the host system 
interface functions are null, that is. straight passthroughs 
to system intrinsics. Ultimately, the host system interface 
modules could grow to constitute a small operating system 
in themselves when less functionality is provided by the 
host machine. Notice that only these modules call the host 
operating system directly and, therefore, they contain the 
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only nonportable network code. 

Together, the execution environment and host system 
interface modules provide multitasking with process syn- 
chronization, memory management and accounting, inter- 
task message and queue management, nodal management 
(which controls and coordinates all the other modules in 
the network subsystem), utilities for manipulating the 
shared-memory protocol interface data structures, and a 
library of miscellaneous utilities (like hashing routines*) 
which are of general use for protocol modules. 

Fig. 4 shows the logical organization of a protocol build- 
ing block. This block encapsulates the code for a given 
protocol. The main function of the network implementa- 
tion architecture is to define the interfaces between a pro- 
tocol building block and the blocks above it (which use its 
services), the blocks below it (on which it depends), and 
the execution environment. The upper and lower interfaces 
are represented by shared-memory data structures. The ac- 
tions that take place at each interface are represented by 
specific message types. 

The lower interface for a protocol building block consists 
of one or more functional ports — usually one. A functional 
port can be visualized as a terminal strip of female electrical 
sockets. (The related OS1 concept is called a service access 
point.) 

The upper interface to the protocol building block con- 
sists of an endpoint for each of the protocol's instances of 
communication with a remote machine. An endpoint can 
be visualized as a male plug that attaches to a specific 
functional port of a higher (the using) protocol. (The OSI 
endpoint term refers to the following concept: Each pro- 
tocol building block regards an endpoint just below it a 
the end of a data path "wire" that will carry its data tc 
peer protocol module in a specific remote machine.) 

The protocol building blocks are "plugged" together by 
nodal management for each instance of communication 
with a remote machine as shown in Fig. 5. This chain of 
protocol building blocks is referred to as a data path and 
is represented as a linked list of endpoint data structures. 
Data paths can join or branch to represent multiplexing or 
alternate routing. Fig. 5 shows the data path that supports 
an instance of network file transfer (NFT). All data and 
control information related to moving a file between the 
local and remote machines is carried by internal messages 
flowing along this data path. 

Note that in the current version of LAN 9000 there are 

■Routines used to organize tables for rapid searching or look-up 



several alternative building blocks at the services level. In 
the future, there will also be alternative modules at all the 
other levels as well. The protocol building block structure 
will allow nodal management to plug together any combi- 
nation of alternative modules that is appropriate for reach- 
ing a particular remote machine. For example, the endpoint 
underneath the internet protocol could just as easily belong 
to the X.25 protocol* block, which would then be served 
by an endpoint belonging to the LAPB (link access protocol, 
balanced mode) I/O card. Also, the NFT protocol could be 
supported by an entirely different set of transport protocols. 
We have already used the nodal management capability to 
replace protocol building blocks by arranging data paths 
through alternative modules. During development, we used 
alternate data paths to inject special test modules at various 
points above or below the code being developed. 

The architecture described above solved three primary 
problems. It isolated us from the operating system and 
processor set by providing a series of common function 
calls which we could create in any operating system. It 
defined a series of interfaces between protocol modules so 
that we could mix and match many protocols. These inter- 
faces were based on proposals in the ANSI and ISO commit- 
tees. Finally, these interfaces allowed various protocol de- 
signers to design with some degree of independence and 
still be sure that the system would bean integrated package. 

We were concerned at first that creating all these module 
interfaces would cause performance problems, but that was 
a price we were willing to pay for the flexibility the ar- 
chitecture would give us. In the end, we were pleasantly 
surprised to find that with just a minimum of tuning, our 
performance was as good as or better than many other 
similar systems on the market. The code modularity and 
the architecture increased the productivity of our design 
group with no loss of performance. 

Quality Assurance 

It has long been a policy at our facility that the engineer 
who designed and implemented a module is responsible 
for the quality of that module. Following this policy, the 
designers wrote the test plans for their individual modules. 
This included both black-box and white-box testing. Here, 
black-box testing is based on the user manual or external 
specification of the module. White-box testing is based on 
knowing how the module was designed and stressing it at 
its weak points. Designers were responsible for doing their 
own white-box testing, and many also did their own black- 
box testing. The exception was when the module was de- 
signed to be used by HP customers directly. At this point, 
an independent tester was assigned to do the black-box 
testing to give us an independent opinion on the usefulness 
of the module. 

The test plans formed the basis for determining when 
we were finished testing. They were also used for schedul- 
ing this phase of the project. One of the best indicators of 
when the quality of the product is high enough to ship to 
customers has been "Did we complete the test plan?" This 
is one reason the test plan is reviewed by the quality assur- 
ance department to ensure that it is rigorous and complete. 

"The CCITT standard miertace protocol lor packet switching networks This standard con- 
sists of three protocol layers that conform to the lower three levels ot the OSI model 
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The other major indicator of quality is a measure of the 
mean time to failure. This time is the machine time spent 
stressing the code in new ways, plus a derated amount of 
machine time spent running old test programs, divided by 
the number of failures detected. 

Since completing the test plan usually takes some time, 
we used a completion estimate for scheduling this phase. 
Each designer estimated the hours necessary to design each 
of the tests in the test plan. We then calculated the amount 
of time necessary to find and fix code and design errors 
from our historical data. Finally, we allotted time for over- 
head and unanticipated activities. After completing these 
estimates for each designer, we estimated that the test phase 
would take about 15 weeks. Since the test plan was actually 
completed in 16 weeks, we felt our estimate was quite 
good. But at this point we still had not met our goal for 

mean time to failure. 

In the course of doing testing, we came upon a new test 
method that we called triggers. Triggers is a method of 
triggering asynchronous events to occur at particular times. 
For example, if a routine asks for blocks of memory three 
times in its execution, we can trigger the system to reject 
the memory request al any of those three times. The trigger 
mechanism allowed us to test most of the paths in our 
code. It was this trigger mechanism that kept our measured 
failure rate so high in the beginning. Even though most of 
the events detected by the triggers were very improbable 
in real life, we continued to test for them until the triggers 
could not produce any more errors. Then we felt that we 
had a very solid system and we finally met our mean time 



to failure goal. This additional test time took another four 
weeks, but we felt the added code quality was worth the 
effort. Most of the problems we solved with this technique 
would have been very difficult to find and correct once 
the product was in a customer's hands. 

Future Directions 

The current version of LAN 9000 establishes the base to 
grow into additional topologies. The evolution will be in 
the directions of connectivity to more kinds of workstations 
and systems, additional links and gateways, and inclusion 
of more industry standard protocols. The architecture pro- 
vides the flexibility to add protocols, and it facilitates the 
porting of the network software to other systems. 
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A General-Purpose Operating System 
Kernel for a 32-Bit Computer System 



by Dennis D. Georg, Benjamin D. Osecky, and Stephan D. Scheid 



THE OPERATING SYSTEM KERNEL for the HP 9000 
Series 500 Computers efficiently supports the real- 
time requirements of the extended BASIC language 
environment as well as the multiuser requirements of 
HP-UX. The kernel provides efficient support for multiple 
processors, a process model that supports a large user pro- 
cess virtual address space, a virtual memory system that 
supports both paged and segmented virtual memory, mem- 
ory and buffer management, and a device-independent file 
system which has the capability of supporting multiple 
directory formats. The main objective of this operating sys- 
tem kernel, called SUN, is to provide a clean interface 
between the underlying hardware and the application-level 
systems such as BASIC or HP-UX. 

The SUN operating system can be separated into two 
sets of major components, as follows: 



I/O 

Input/Output Switch 
Device Driver Modules 
Input/Output Primitives 



Non-I/O 

Process Manager 
Memory Manager 
Buffer Manager 
Message Manager 
Timer Manager 
Trap Manager 
Dispatcher 

Nonvolatile Memory Manager 
System Startup Manager 



The I/O components of SUN are described on page 38. 

The SUN operating system manages the allocation and 
deallocation of hardware resources. Memory and proces- 
sors are the primary system resources. Other resources in- 
clude buffers, message queues, file directories, input/out- 
put channels, processors, and timers. The management of 
these resources supports: 

■ The establishment of contexts (sets of code and data 
addresses) for the execution of sequences of instructions 

■ The allocation of the processor to the execution of spe- 
cific sequences of instructions 

■ The dynamic allocation of resources required by the al- 
gorithms being executed. 

Hardware and Operating Environment 

The Series 500 hardware provides a stack-oriented envi- 
ronment for program execution. 1 Segmentation and paging 
are used to facilitate memory management. A simplified 
diagram of the operating environment is shown in Fig. 1 
on page 35. 

There are two basic types of segments: code segments 
and data segments. Code execution on a Series 500 CPU is 
contained in one or more code segments and uses several 



data segments. One data segment is used as an execution 
stack segment and at least one other data segment is used 
as a global data segment. Each CPU contains hardware 
registers to define and bound the current code, stack, and 
global data segments. Other segments, called external data 
segments, can be accessed indirectly through pointers 
stored in the stack and global data segments. External data 
segments can be paged. 

Information to manage the segments is kept in tables — 
one system segment table and many user segment tables. 
However, only one user segment table can be active on a 
CPU at a given time. The system segment table and the 
currently active user segment table define the address range 
of the program running on a CPU at any time. 

A device reference table contains an entry for each I/O 
channel. This entry contains information to establish the 
code segment and global data segment for the interrupt 
service routine when the corresponding I/O device requests 
service. Each CPU has an interrupt control stack which 
serves as the execution stack for interrupt service routines 
and for the system dispatcher. 

The CPU hardware defines a task control block to de- 
scribe the state of a task. This block contains a pointer to 
the user segment table for the task and to the task's stack 
and global data segments. The CPU microcode uses four 
words of memory for each CPU in the system. These CPU- 
dedicated locations point to the current user segment table, 
the currently executing task control block, and the interrupt 
control stack for the CPU. 

Contexts 

For this discussion, a context is a set of related addresses 
that define a scope of addressability, that is, limit the set 
of code and/or data addresses that are accessible. The SUN 
operating system supports program, process, and partition 
contexts. 

Program Context. The simplest context is a program, a set 
of one or more procedures. Each procedure is a collection 
of instructions, with a common entry name, which may or 
may not be parameterized. Instructions that make up a 
program are stored in code segments. A program may oc- 
cupy one or more code segments or several programs may 
reside in one code segment. The address range (context) 
of a program is the set of code segments that it occupies. 

During program execution, procedure parameters and 
local variables and an execution stack are stored in a special 
data segment called the stack segment. Program variables 
that are not local to program procedures or parameters to 
those procedures can be stored in either the global data 
segment or in arbitrary additional data segments called 
external data segments. External data segments are only 
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allocated as a result of explicit requests and can be either 
paged or unpaged. 

The context of an executing program or process also in- 
cludes the current values of the hardware registers, which 
define the current state of the hardware and the relative 
state of the process. The hardware state of a process can 
be established using information from the process' task 
control block and stack segment. 

While a program has a static context, a process is an 
active element with a dynamic context. In SUN. a process 
is defined to be a unique instance of a consecutively execut- 
ing program, and more than one process can share a pro- 
gram. The primary operational characteristic of a process 
is that the progress of any process in the system, as it 
executes its code body, is not guaranteed relative to the 
progress of other processes in the system. 
Process Context. The minimum context for a process con- 
sists of the program context, stack and global data segments, 
and the current hardware state. Each process has its own 
stack segment. Process contexts can be expanded by the 
addition of an arbitrary number of external data segments. 
They also can be dynamically varied by allowing the 
executing program to switch global data segments dynam- 
ically, create and delete external data segments, or extend 
or contract existing segments. 

Partition Context. A partition is a set of processes that 
share a common user segment table. This segment table 
has entries for the code and data segments that are local 
to the partition. Since the segment table entries contain 
the base address locations of the allocated segments as well 
as their current lengths, the segment table defines the seg- 
ments the partition can address. 

Other than the availability of memory and segment table 
space, there is no limit to the number of processes that can 
exist simultaneously in a partition. All processes within a 
partition can share the same global data segment, This seg- 
ment represents the primary mechanism for sharing data 
among a set of processes within a partition. 

User partition contexts are created as a result of calls to 
the START PARTITION procedure. The procedure parameters 
specify the information required to construct a partition 
context as well as the context of the inital process that is 
to be created and executed within the created partition 
context. The execution of START PARTITION allocates the 
initial physical memory for the partition, initializes the 
segment table for the partition, allocates the global data 
segment for the partition, and establishes the context for 
the initial process in the created partition. The initial pro- 
cess can request additional resources, or create additional 
process contexts. Like any other process in the system, the 
progress of the execution of the initial process in the created 
partition depends on its priority relative to other processes 
and the number of other processes in the system as a whole. 

A partition is deleted when the last process in that par- 
tition terminates. The resources that make up the partition 
are then returned to the appropriate pools of available re- 
sources. 

System Partition Context. The system partition is a special 
context defined by the system segment table. Segments 
described by the system segment table are addressable at 
all limes. The union of the segments in the system segment 



table and the current user segment table defines the context 
of the machine at any time. The system segment table con- 
tains the system global data segment and other segments 
that can be shared by all processes in all partitions because 
of their global addressability. 

Even,' process context is allocated from within a partition 
context. There are two classes of processes: user partition 
processes and system processes. The main distinction be- 
tween user and system processes is the addressability of 
the stack for the process. The stack segments of system 
processes are allocated from the system segment table and 
are therefore always addressable. A system process can 
establish addressability to any partition context by chang- 
ing its current user segment table, which together with the 
system segment table, defines the current address space. 
User processes cannot address any segments described in 
any user segment table other than their own. 

Process contexts can be deleted explicitly or implicitly. 
A call to the SUN procedure PTERMINATE causes explicit 
termination of the current process. Implicit deletion occurs 
when the program being executed completes execution and 
exits its initial procedure. Regardless of whether the dele- 
tion occurs explicitly or implicitly, the effect is the same. 
The resources used to construct the process context are 
returned to the system for reallocation. 

Processes in the subsystems supported by SUN always 
execute within the context of a partition. Process contexts 
established in a partition context can be used to control 
asynchronous events or devices, simplify the solution to 
an otherwise more complex problem, provide execution 
environments that have special characteristics such as 
specialized trap handling procedures, or separate the 
execution of subsystem-supplied code from that of code 
developed by a user. 

An example of a process set provided by a language 
subsystem is the model developed by the BASIC language 
subsystem for the HP 9000 Model 520 Computer, an inte- 
grated desktop workstation. Each BASIC partition has ac- 
cess to a system human interface process and separate run 
and executive processes. The human interface process 
manages access to devices such as the Model 520's 
keyboard and CRT. which are controlled asynchronously 
by the user interacting with the machine. The executive 
process controls the slate of the partition's run process, the 
parsing of language and command statements, and the com- 
munications with the human interface process. The run 
process performs the run-lime compilation and execution 
of BASIC programs written by a user. 

Resource Allocation and Addressability 

In most cases, memory object resources are allocated 
from the partition containing the process making the re- 
quest. For example, a request for the allocation of a data 
segment by a process within a user partition context results 
in the allocation of the segment from that partition's seg- 
ment table. However, processes executing within user con- 
texts also have an ability to allocate/deallocate memory 
object resources from the system context explicitly. Pro- 
cesses executing within the context of one user partition 
cannot directly allocate/deallocate resources within another 
user partition context. 
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Parallel Development of Hardware and Software 



One of the earliest goals ol the Model 520 Computer (the 
desktop version ol the HP 9000 Series 500) project was to bring 
the completed system to the marketplace as soon as possible 
after completion ot the hardware. The traditional projecl pattern 
m which development of the software takes place after Ihe com- 
pletion of the hardware was therefore inappropriate. 

To increase both the productivity of the software development 
team and the resultant quality of the final system software, a 
high-level language was designed to be used for all systems 
programming. This language, called MODCAL, is based on Pas- 
cal, but includes enhancements to allow separate compilation 
and to provide controlled access to certain architectural features 
of the HP 9000 Series 500 Computers so that the temptation to 
code in assembly language is greatly reduced. Since the lan- 
guage was used to implement the most fundamental parts of the 
SUN operating system, it was designed in such a way as to be 
support-free. No supporting libraries and operating system are 
inherently assumed to exist by the compiler The match between 
the language and the underlying architecture is further improved 
by the addition of a good compiler code optimizer, resulting in 
even less temptation to resort to assembly language. 

With this strategy it was possible to develop most of the soft- 
ware modules which make up the system. At the end of the 
proiect more than 96% of the system software had been coded 
in MODCAL. This percentage included the results of extensive 
tuning efforts in which modules found to be critical to the perfor- 
mance of the machine were recoded in Series 500 assembly 
language. This overall stategy not only improved the productivity 
of the development team, bul also resulted in a product with 
much better software reliability and maintainability. 

Although it was possible to test higher-level modules by execut- 
ing them on another system with simulated lower-level routines, 
it became apparent that the only acceptable way to check out 
lower-level, architecturally dependent software was to run the 
code in an environment that fully duplicated the characteristics 
of the final system. This requirement was especially critical for 
testing I/O driver code. Not only did it require the duplication of 
the CPU and I/O processor functions, but also the semantics of 
an I/O device. 

To allow all parts of the system to complete testing and inte- 
gration before the availability of functioning hardware, a detailed 
software emulator of the Model 520 was built. This emulator in- 
cludes detailed modeling of all parts of the CPU.' memory con- 
troller, 2 and most significantly, the I/O processor 3 and backplane 

The HP 9845 Computer, configured with an assembly language 
development ROM, was selected as the engine for the emulator. 
The friendliness of the assembly language development environ- 
ment allowed high productivity during the emulator development. 
The memory system of the HP 9845 was sufficiently large (500K 
bytes) and the overall system cost was low enough to allow 
several systems to be purchased for the emulation function. The 
last consideration was of extreme importance since the operation 
of the emulator is by necessity very computation-intensive and 
one or two copies of the emulator executing on a timesharing 
system would have completely consumed the system's proces- 
sor. Furthermore, the HP 9845 was also used as a MODCAL 
development station, allowing a complete development station 
to exist on an engineer's desk 

The emulator was implemented in stages. The functionality of 
the CPU registers and a sufficient fraction of the instruction set 
to allow the lowest levels of the operating system to be coded 
and tested were provided first. This allowed most of the operating 



system kernel to be tested sufficiently to ready it for integration 
with partially tested higher-level software. Work on the emulator 
then continued to implement the instruction set more completely 
by including floating-point instructions and all instructions emitted 
by the MODCAL compiler Most of the BASIC software system 
could be tested with the exception of the I/O drivers, file system, 
and human interface. A temporary I/O interface was added which 
allowed simple read and print I/O to take place to the keyboard 
and display of the HP 9845. 

Next, Ihe complete I/O processor and I/O backplane emula- 
tions were added. This consisted of software to model the state 
of the I/O processor connected to an external device which pro- 
vided the hardware simulation of the new I/O backplane of the 
Model 520. Simulation of I/O device semantics could then be 
provided by actual I/O devices. This approach worked well for 
devices that were available for use, but a number of I/O devices 
were still under development A capability was added that al- 
lowed software simulation of these unavailable devices. 

Code was added to the emulator to capture dynamic measures 
of instruction and memory access mode use. The execution 
monitor function supported by these additions allowed the soft- 
ware development team to evaluate coding alternatives and to 
begin tuning the system before hardware was available. The 
functionality of the emulator was tested during its development 
by a battery of architectural verification tests which were de- 
veloped in parallel with the emulator. These tests not only served 
as a cross check on the correctness of the emulator, but they 
were also used as verification tests for the NMOS-III chips when 
preliminary versions became available. 

The finished emulator allowed complete integration of all com- 
ponents of the Model 520 s BASIC system, including the human 
interface and I/O drivers. The execution rate of the software was 
1000 times slower than real lime, but was sufficient to allow 
BASIC statements to be stored at the rate of one every 20 sec- 
onds. At this point some of the software modules were sufficiently 
stable to allow the start of quality assurance testing. 

Finally the hardware was ready The 350K-byte BASIC operat- 
ing system was loaded Into the prototype and the system was 
functional. The parallel development strategy was successful. 
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Other types of objects can be allocated by calls to the 
operating system. Buffers are contiguous sections of mem- 
ory that are guaranteed never to be relocated and can there- 
fore be referenced by using absolute addresses. Buffers are 
mainly used by the I/O part of SUN as temporary holders 
of data being transferred either to or from an I/O device. 

A message link is a queue receptacle to which messages 
can be sent and from which messages can be received. 
Message links are allocated by SUN from a segment that 
exists in the context of the system partition- 
Resources allocated from the system partition have global 
addressability since all partitions see the system address 
space as part of their address space. Resources allocated 
in partitions other than the system partition cannot be ad- 
dressed from other user partitions. The ability to address 
user partitions is provided to system processes via the pro- 
cedure CHANGE_TO_PARTITION . which establishes user ac- 
cess to the specified partition. 

Virtual Memory 

The operating system provides support for virtual mem- 
ory used in HP-UX in the form of both segmentation and 
paging. Virtual segments are treated as indivisible entities 
of variable length that can be swapped to a storage device 
when not in use. Virtual objects can also be allocated in 
paged external data segments which are divided into equal 
pieces called pages. Each page can reside in physical mem- 
ory independent of the other pages that make up the object. 
Virtual segmented objects can be up to 500K bytes in size, 
while virtual paged objects can be up to 500M bytes. 

The hardware provides indicators for each virtual object, 
allowing the operating system to determine if the object is 
currently in physical memory, and if it is, to determine 
whether the object has been referenced and/or modified. 
The operating system uses this information in its replace- 
ment algorithms to choose segments or pages to be removed 
from physical memory when necessary. 

The operating system supports the sharing of virtual ob- 
jects among several processes. It also supports the mapping 
of files into virtual objects, thus providing access to a mapped 
file at memory speeds. Virtual objects can also be locked 
in physical memory to prevent relocation during I/O trans- 
fers to or from the object. 

Communications 

SUN and the language and applications subsystems sup- 
ported by it are sets of communicating processes. The initial 
process within the user context is free to develop an arbi- 
trary set of processes. No structure is imposed on the pro- 
cess set within user partition contexts. However, all pro- 
cesses within a partition context share a global data seg- 
ment and other segments that they can commonly address. 

The simplest form of communication occurs al process 
creation when a single-segment relative pointer is passed 
as a parameter to the program to be executed in the new 
process context. This pointer can have no value or can 
point to an arbitrary parameter structure. This level of com- 
munication is similar to the parameter passing that occurs 
when one procedure calls another procedure within the 
same process context. 

Processes executing within the same partition context 



can share data in the global data segment or other external 
data segments defined in their common segment table. All 
processes can share data in segments defined in the system 
segment table. Pointers to shared data or the shared data 
itself are stored in global data segments that are common 
to the communicating processes. 

In addition to supporting communication via inter- 
process parameter passing and shared data in global data 
segments, SUN supports communication via message pass- 
ing. This support is provided by the message manager com- 
ponent. The message manager supports interprocess global 
communication by allowing one process to construct a 
packet of information called a message, send that message 
to a mailbox, and have a different process at an later time 
receive the message from the same mailbox. Processes com- 
municating via messages can exist either in the same or 
different partition contexts. All that is required to initiate 
the communication is knowledge of a common message 
mailbox name, which SUN refers to as a message link. 

Synchronization and Scheduling 

Semaphores and semaphore operations are used to syn- 
chronize and coordinate processes. A semaphore is im- 
plemented as a two-word data structure that can be allo- 
cated anywhere that can be commonly addressed by the 
synchronizing processes. There is no limit on the number 
of semaphores that can exist in the system. They are used 
to protect and provide exclusive access to shared data and 
to block a process until signaled by another process. 

The semaphore operations are designed to be safe in a 
multiple-processor environment. By safe, it is meant that 
the operations on semaphore data objects are guaranteed 
to be indivisible and complete regardless of the number of 
processors in the system. A more complete description of 
the operation of the process synchronization primitives 
can be found in the article on page 34. 

SUN also provides procedures for synchronizing pro- 
cesses with time. These procedures allow processes to wait 
for a specified time interval or to wait until a specified 
absolute time. Absolute times and intervals are specified 
as floating-point numbers in units of microseconds. 

At any time, all processes can be divided into two groups: 
runable and blocked. In addition, a subset of the runable 
processes is actually executing on the CPUs of the system. 
In a system with n CPUs, up to n processes can be executing 
at the same time. Processes become blocked by explicitly 
downing a semaphore, attempting to receive a message 
that has not yet arrived, or waiting on a timer. 

The SUN operating system supports sets of subsystems 
that, in general, have more processes to be run than proces- 
sors. The dispatcher provided by the operating system is 
responsible for selecting runable processes to be executed 
by the CPUs based on process priority. Entry to the dis- 
patcher occurs whenever a dispatch instruction (DISP) has 
been executed and the current state of the system allows 
the dispatcher to be entered. The DISP instruction is exe- 
cuted by process synchronization and manipulation primi- 
tives when the state of a process is modified. In particular, 
the dispatcher is entered whenever a currently executing 
process is blocked, when a process that is of higher priority 
than a currently running process is made runable, or when 
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A System Software Debugger 



For the VLSI chip set used in (he HP 9000 Series 500 Comput- 
ers, two available levels of debugging evolved The low-level 
capability uses a separate HP 9845 running a huge BASIC pro- 
gram, attached to another electronic tool, which in turn connects 
to the NMOS-I II CPU or I/O processor debug ports The high-level 
debugger is a large software package that is linked with an 
operating system It uses debugging support tools built into the 
microcode to help programmers debug that system 

Major Features 

The debugger supports stepping, breaking, and profiling at 
the procedure, statement, and machine instruction levels, 
examines and changes memory and I/O in a variety of ways, 
disassembles machine instructions, dumps process status, pro- 
cedure chains. CPU registers, stacks, and variables, executes 
procedures, prints hard-copy audit trails, and passes control to 
user-defined debugging software 

The debugger is menu-driven. Most command prompts are 
less than one line long. Each command is a single letter that is 
accepted as soon as it is typed . Given the speed of the underlying 
hardware, this makes for a responsive, natural-feeling human 
interface which combines the best of both menu and command 
line styles. Novices find the debugger easy to use for quick, 
simple interactions Experienced users tend to learn short com- 
mand sequences that accomplish common operations. 

The menus range in length from short (two options) to quite 
long (twelve options at the top level). Most functions are only two 
or three levels deep, and every menu but the top one can be 
exited by typing O (options). 

Most menu lines are cleared after the user responds, which 
keeps the visual clutter to a minimum. When multiple-character 
input is required, the debugger requests it between menus in 



the priority of a currently running process is changed. This 
ensures that the highest-priority process in the set of run- 
able processes is selected for execution. 

The dispatcher completes the state-saving operation in- 
itiated by the DISP instruction, selects the highest-priority 
runable process, marks the selected process as running, 
restores a subset of the hardware registers based on values 
stored in the task control block associated with the selected 
process, and executes an interrupt exit (IXIT) instruction. 
The IXIT instruction causes the remainder of the hardware 
state to be restored and process execution to resume. 

Interrupt Handling 

The normal flow of the execution of the machine instruc- 
tions can be modified by three mechanisms: external inter- 
rupts, internal interrupts, and traps. External interrupts 
signal requests for service by I/O devices. Internal inter- 
rupts signal abnormal conditions within the system that 
are not associated with the execution of a machine instruc- 
tion. Traps differ from interrupts in that traps result from 
conditions detected by the hardware during the execution 
of an instruction. The detailed handling of interrupts and 
traps is done by the operating system. 

The hardware defines 16 priority levels that can be as- 
signed to each I/O channel. The interrupt structure is such 
that a higher-priority device preempts a lower-priority de- 



as compact a form as possible. 

The first four options— Pstep, Step, Focus, and Resume — on the 
top level resume the current process, either stepping at the pro- 
cedure, statement, or machine instruction levels, or resuming 
execution with no change of debug state. The Break option sup- 
ports maintenance of procedure, source statement, machine in- 
struction, memory location, and external process breakpoints. 
Machine instruction breakpoints can be local (one process only) 
or global (all processes) Clear sets the state of the debugger to 
free-run 

The Exam option leads to a powerful memory and I/O access 
capability For examining memory, it first allows the user to specify 
the initial memory location in one of a number of ways, either as 
an absolute address, relative to various data registers and seg- 
ments, or by variable name or program location. Then it supports 
forward and backward stepping through and lumping around 
memory, going indirectly through data and absolute pointers 
(with a return stack), modifying locations, and viewing arbitrary 
byte sequences Meanwhile, the Exam lo option supports simple 
I/O requests and status displays. 

The Dump option capabilities include task status, accumulated 
CPU use by processes, procedure calling chains, CPU registers, 
and stack and variable dumps. The exec option allows users to 
call any procedure in memory, with a specified parameter list, 
under debugger control The Toggle option controls debugger 
modes, including partial and full hard-copy audit trail printing. 
The Meas option interacts with the optional procedure, source 
statement, and machine instruction execution and coverage 
monitor (profiler). 

Finally, the twelfth option, Ud. leads to a user-defined debugger, 
if one is present. Software authors can easily write their own 
extensions and plug them in at link time. 



vice. Furthermore, a special hardware register, called the 
mask register, can be used for the purpose of masking off 
specific priority levels. The initial handling of external 
interrupts is done by the CPU microcode interrupt handler. 
The interrupt handler is executed on behalf of a particular 
device when all of the following conditions are met: 1 ) the 
device has requested an interrupt, 2) interrupts at the de- 
vice's priority level are not masked, 3) the interrupt bit in 
the status register is enabled, and 4) no higher-priority 
device is requesting service. 

The interrupt handler initially saves the state of the 
machine by pushing a stack marker onto the stack segment 
for the currently executing process. The stack marker con- 
tains the information necessary to restore the status of the 
interrupted process, and hence allow execution to resume 
later. The information includes the index register value, 
the address of the first instruction to be executed when the 
machine status is restored, the machine status indication 
register, and a pointer to the previous stack marker. 

External interrupts are handled on a special stack seg- 
ment called the interrupt control stack. In this case, the 
CPU registers are modified to point to different stack and 
global data segments before the execution of the interrupt 
service routine. Before this register modification, the values 
of the registers associated with the interrupted process are 
saved in the process' task control block and stack segment 
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The debugger contains a complete user l.'O facility for 
keyboard input and display and optional hard-copy output Like 
most parts ot the debugger this code is as independent as 
possible of any particular operating system implementation 

Most of the debugger I/O and mode-control routines (about 
34 in all) are exported to the rest of the system software This is 
especially invaluable for debugging system I/O software and for 
supporting miscellaneous lest harnesses 

The debugger includes two optional packages which can be 
included at link time If the disassembler is present, all displays 
of code are disassembled while examining, dumping, or step- 
ping. If the execution monitor (profiler) is present, the Meas option 
comes alive, adding a number of features 

The debugger is part symbolic. Compile-time options permit 
each procedure to be followed by a short symbol table, including 
a procedure name and possibly variable names and locations 
If this information is present, the debugger uses it wherever it 
can. Debugging of "nondebuggable" procedures is still possible, 
but procedure and variable information is entered and displayed 
strictly by numeric address. 

Implementation 

This debugger is intraprocess. not interprocess. Rather than 
occupying one or more dedicated debugging processes that 
interact with others, the debugger is inactive until invoked. If the 
debugger is present, every process has a small amount of space 
(about 240 bytes) set aside at the base of its stack for permanent 
debugger variables. The debugger uses almost no other data 
storage. 

When activated, the debugger runs on top of whatever process 
invokes it To ensure a stable environment, it turns off interrupts, 
takes exclusive control of the machine (pausing all other CPUs), 
and is careful nol to relinquish that control until exited. 



The operating systems supply a limited numper of special 
support routines to help the debugger gather information about 
and control other processes and operating system data struc- 
tures Tnese routines help insulate the operating system and 
debugger from each other, maximizing independence 

The VLSI chip microcode provides a handy set ot debugger 
support features There are a number of special assembly instruc- 
tions wmch. when enabled, cause software traps that lead lo the 
debugger (if present). These instructions are planted in debug - 
gable code by the compiler and enabled by the debugger on a 
process-local oasis as needed for simple, efficient procedure 
and source statement stepping Since the status register does 
the enabling/disabling, the debugger state becomes a part of 
the process state The CPU microcode also supports machine 
instruction stepping and a single absolute-address break regis- 
ter, both of which operate through the trap mechanism 

The debugger is linked with one of a number of low-level I/O 
driver modules, each of which provides the same exported pro- 
cedure names These modules allow the debugger to run on an 
emulator, or on real hardware with the Model 520's keyboard 
and its various display options, or via an ASI or multiplexer card 
connected to a dedicated terminal. 
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so that they can be restored before the process resumes. 

The interrupt handler writes the device number of the 
device requesting service onto the interrupt control stack 
at a known location. The device number serves as an index 
into the device reference table, which contains an entry 
for each I/O channel. The device reference table entry for 
a requesting I/O device is chained by an I/O processor onto 
a queue corresponding to the priority of the device to await 
service by a CPU. Each device reference table entry contains 
a pointer to the interrupt service routine, and a pointer to 
the data relevant to that I/O channel. 

The SUN operating system contains a single main inter- 
rupt service routine. Device driver procedures are executed 
by system and user processes as a result of input/output 
requests. When a device driver procedure wants to wait 
for an interrupt, the procedure calls a special operating 
system primitive which executes a DOWN operation on a 
semaphore associated with the device, thereby blocking 
the executing process. The interrupt service routine does 
an UP operation on a semaphore associated with the device 
driver procedure that handles interrupts for the interrupt- 
ing device, and thus unblocks the process which had been 
waiting for the interrupt. The interrupt service routine exe- 
cutes an IXIT instruction which may force the execution of 
the dispatcher if the freed process is of higher priority than 
the currently executing process. If the unblocked process 
is not dispatched, then the state of the interrupted process 
is restored and its execution continues. 



The hardware detects 45 different traps, or exception 
conditions. These traps are catagori/.ed into seven classes 
by the operating system to make exception handling more 
manageable. The seven classes are system, address, pro- 
gram, instruction, stack overflow, trace, and debug traps. 
System traps include absent segment and absent page traps, 
and other traps that support virtual memory. 

The trap manager component enables traps other than 
system traps to be handled by the higher-level subsystems 
in a hierarchical manner. Trap handling routines can be 
specified that apply to a specific process, to all processes 
in a given partition, or to all processes in the system. Trap 
handlers installed at the process level have the option of 
either handling the exception and returning to the inter- 
rupted process or referring the trap to the partition level. 
Similarly, partition level trap handlers can optionally refer 
handling to the system level. 

Protection 

The subsystems supported by the SUN operating system 
benefit from the protection of system integrity supported 
by the hardware as well as the protection provided by SUN 
itself. The protection provided by the hardware falls into 
three categories: segment bounds checking, mode checking, 
and segment attribute checking. 

All segment (data or code) references are checked by the 
hardware to ensure that the references are within the 
bounds of the segment. Furthermore, any attempt to write 
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to a segment is checked to ensure that the segment is writ- 
able. All segments also have an attribute that indicates if 
the segment can be accessed by code that is designated as 
unprivileged. This prevents user processes from directly 
executing code that is strictly for internal system use. Any 
violations are detected by the hardware and cause traps. 

The operating system provides protection beyond that 
provided by the hardware by providing an independent 
partition segment table for each user partition context. Seg- 
ment accesses within a partition are limited to segments 
within the system segment table and to segments within 
the segment table local to the partition. In addition, SUN 



provides addressability checks at critical points in the 
execution of its procedures. 
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The Design of a General-Purpose Multiple- 
Processor System 

by Benjamin D. Osecky. Dennis D. Georg, and Robert J. Bury 



ALTHOUGH A NUMBER of earlier Hewlett-Packard 
products have contained multiple-processor config- 
urations, none has been able to bring the full power 
and flexibility of these processors to bear in solving user 
problems. For instance, the HP 9845B Computer contains 
an identical pair of 16-bit processors with shared memory. 
However, the system architecture constrains one processor 
to handle the computational parts of a user's program while 
the other processor, which accesses only the I/O bus, man- 
ages the input/output and other operating system functions. 
Although this partitioning of functions provides a perfor- 
mance advantage over a single processor for applications 
in which the requirements for I/O and computation are 
relatively balanced, the configuration does little to improve 
the performance of strictly computational or mostly I/O- 
oriented workloads. 

Many other multiple-processor systems exhibit forms of 
asymmetry between their computation and input/output 
functions which are a result of either their hardware or 
their software architecture. On some systems a particular 
I/O device can be accessed by only a subset of the proces- 
sors. Communication with such a device requires either 
complex communication protocols between the asymmet- 
ric processors or constrained execution of the user program 
on the processor subset. Other multiple-processor systems 
allow only a single processor at a time to execute operating 
system code. 

Hardware Design 

The hardware architecture of the HP 9000 Series 500 
Computers has been designed to provide for a fully symmet- 
ric multiple-processor architecture. All CPUs. I/O proces- 
sors, and memory controllers are interconnected by the 
memory processor bus. All I/O processors and memory are 



identically addressable by all CPUs. This implies that a 
program can execute on any of the system's processors 
without any changes to the way the system addresses either 
memory or I/O devices. Perhaps equally important is the 
fact that all I/O processors have an equally symmetric view 
of CPUs and memory. This makes it possible for a program 
to initiate an I/O operation on one processor, for the inter- 
rupt service routine to execute on the same or a different 
processor, and lor the user program to continue on a third 
processor, all with complete transparency. 

This symmetry is also exploited to improve system relia- 
bility. When the system is turned on, the processor compo- 
nents perform a self-test and report their results to one of 
the processors which is temporarily designated as a master. 
This master CPU begins the execution of operating system 
code that determines the number of system components 
that have passed their self-tests and configures the system 
based on these working components. Once the system has 
been configured, the distinction of the master CPU is can- 
celed and the system begins normal operation, except for a 
possible loss of capacity caused by any failed components. 

For a multiple-processor system to be able to deliver a 
significant performance improvement over a single proces- 
sor, each processor in the system must be provided with 
sufficient bandwidth to the system memory. In the HP 9000 
Series 500 Computers, the memory processor bus provides 
a bandwidth of 36M bytes per second. The memory con- 
trollers are fully pipelined and are capable of responding 
to arbitrary reference strings at this maximum bandwidth. 
Measurements of the bandwidth consumed by a single 
Series 500 processor indicate that the average consumption 
is approximately 9M bytes/s. 

Another important hardware characteristic is a test-and- 
set operator that is atomic f indivisible) with respect to mul- 
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tiple-processor execution. This operator is provided by the 
memory controller to allow the execution of a special re- 
quest that indivisibly reads and sets a selected word in 
main memory to a predetermined value. This operator 
serves as a building block for constructing more complex 
synchronization operators in software. This hardware 
operator is also used by the CPUs when accessing certain 
table structures known to the hardware, such as page tables. 
This allows synchronization of access among processors, 
and between processors and the operating system software, 
called SUN, when the table entries must be modified. 

Another important characteristic is the ability to share 
the same image of an executing program between two or 
more processors. This is done by providing an architecture 
in which all code is reentrant. Code is protected from mod- 
ification by the hardware. This allows a single image of 
the operating system to be shared by all processors in the 
system and also allows several processors to be active in 
the operating system code simultaneously. 

Finally, since the SUN operating system was designed 
at the same time as the hardware, it was possible to make 
many hardware/software tradeoffs to improve the perfor- 
mance of SUN. The processor instruction set provides con- 
siderable assistance by saving and restoring process states 
during process switching. Fig. 1 illustrates the process state 
known by the hardware. The task control block is selected 
by a processor register. Information contained in this block 
identifies a process' address space, stack segment and 
global data segment through either system or user segment 
table entries. The process stack contains information at its 
base that allows setting the stack limits and the current 
frame pointer. Absorbing the topmost stack frame allows 
information about the process' code segment and register 
state to be established. This entire procedure is accom- 
plished by the IXIT instruction. This instruction and the 



complementary state-saving operations combine to provide 
fast process context switching times. 

Software Design 

Each process in the system has its own task control block 
and stack segment. The information contained in the task 
control block includes process state information which is 
known to the hardware as well as an extended process 
state maintained by the system software. The state informa- 
tion known to the hardware includes the specification of 
the user's address space, stack, and global data segment as 
described above. The software state includes the process 
priority, its dispatching state, fields to allow the process 
to be queued on a semaphore, a specification of action to 
be taken in the event of an exception condition, and a list 
of objects owned by the process. 

The process priority indicates the relative priority of 
execution of nonblocked processes. The highest-priority 
process not blocked on a semaphore is always allocated a 
processor. If a lower-priority process is running and a 
higher-priority process becomes ready because of some 
event such as the completion of an I/O operation, the lower- 
priority process is suspended and the higher-priority pro- 
cess is given a processor. This mode of scheduling in which 
a higher-priority process can preempt a lower-priority pro- 
cess is referred to as preemptive scheduling. The system 
software was designed to be preemptable in all but a few 
small code sections. 

The dispatching state indicates whether a process is wait- 
ing on a semaphore or a timer, ready for execution, or 
already running on a processor. The address space indi- 
cates which virtual address space contains the memory 
objects local to the process. System processes often coexist 
within the same address space and communicate directly- 
using shared-memory techniques. User processes for both 
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HP-UX and BASIC systems each exist within their own 
address space, which can be up to 512 megabytes. Every 
process also has access to the system address space, which 
can also be as large as 512 megabytes. 

Three different mechanisms are provided to allow the 
synchronization of process activities: locks, semaphores 
and message passing. A lock provides the short-term ex- 
clusion mechanism normally provided by disabling inter- 
rupts while in a critical section on a single-processor sys- 
tem. This same effect is accomplished on a multiple-proces- 
sor system by performing a special code sequence on a 
memory word, referred to as a lock word, that is associated 
with the critical section in question. The exclusion opera- 
tion is performed by executing the instruction read and set 
to -1 and testing the result. If the result is not equal to 
minus one, the lock has been obtained and the critical 
section can be executed. If the lock value is already minus 
one, the processor must retry the indivisible read and set to 
- l instruction until a nonnegative value is read. It is then 
assured that no other processor is active in the critical 
section. When the processor has reached the end of the 
critical section, it stores a zero back into the lock word to 
indicate that the critical section can now be entered by 
another processor. This locking mechanism is used many 
places in the system where exclusion is required for a code 
sequence that is short and does not execute any operations 
that cause the process to be blocked. 

A more general process synchronization tool is provided 
by semaphore operations. The implementation of sema- 
phores is similar to that proposed by Dijkstra. 1 A semaphore 
is a two-word area in memory that contains a value and a 
pointer to a linked list of processes. Semaphores can be 
allocated in memory anywhere that other data structures 
can be allocated, and there is no limit on the number of 
semaphores. Two operators are provided for semaphores: 
DOWN and UP. A DOWN operator applied to a semaphore 
with a value greater than zero merely decrements the value 
associated with the semaphore. If the value is less than or 
equal to zero, the value is still decremented, but the process' 
state is marked blocked and the process' task control block 
is added to the queue of waiting processes associated with 
the semaphore in order of priority. The UP operator incre- 
ments the value of the semaphore. If the initial value of 
the semaphore is less than zero and an UP operation occurs, 
the first process waiting on the queue is marked as ready. 
If the process marked ready is of higher priority than the 
process executing the UP operator, the processor is given 
to the higher-priority process. 

Serialization can be provided for a critical section by 
associating with it a semaphore initialized to a value of 
one and providing a DOWN operator at the beginning of the 
critical section followed by an UP operator at the end of 
the critical section. Synchronization with a server process 
is usually accomplished with a semaphore initialized to a 
value of zero. 

The word used as the head of the queue of tasks blocked 
on a semaphore also serves as a lock word to guarantee 
proper operation of the semaphore in a multiple-processor 
system. Since there is a separate lock word for every 
semaphore in the system, the probability of contention for 
the lock is very low. 



During development of the software, it was found that 
considerable simplification would result by including ad- 
ditional semaphore operators. The first consisted of a con- 
ditional UP operator which would free all processes waiting 
on a given semaphore and allow the passing of an error 
escape code. This operator is especially useful in recover- 
ing from an error condition detected by another process. 
The second consisted of an indivisible DOWN and UP 
operator which would allow a process to block itself on a 
semaphore while releasing another semaphore in one indi- 
visible operation. 

Message passing supports interprocess global communi- 
cations by allowing a process to construct a packet of infor- 
mation called a message, send that message to a mailbox, 
and have a different process at a later time receive the 
message from the same mailbox. Message passing and mail- 
boxes are used by both BASIC and HP-UX system processes 
to coordinate user processes. Sending and receiving mes- 
sages provides process synchronization similar to the 
semaphore UP and DOWN operations, coupled with an ad- 
dress-space-independent data transferral. The message 
passing operations, in fact, are implemented using the 
semaphore operators, which in turn use the locking concept 
at the lowest level. 




| Yes 



Pi 


WAIT 







No 



Was Task Running? 



r 



No 



i Save Rest of Stale 
i Move Task Control Block 
to Queue End 
i Unmark as Running 



T 



Set Up Dummy Low- 
Priority Task Control 
Block 



Search Queue lor Runable 
Task Control Block 



Found 



Mark Task Control Block 
Running. Restore Stale 



Release disp Lock 



Not 
Found 



Release disp Lock 



I 



Fig. 2. Dispatcher flow chart 
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Granularity* 

The duration of a typical process lifetime in HP-UX, 
which can last from a few tens of milliseconds to forever, 
is well matched to the granularity of the underlying process 
model. The BASIC system's process model similarly is of 
reasonably large granularity. The times for representative 
operations for the underlying process model are: 
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To illustrate how the overall process model is im- 
plemented, consider the flowchart of the dispatcher shown 
in Fig. 2. When a DOWN synchronization operation dictates 
a process block, the process is marked blocked and the 
special instruction DISP is executed. This causes the pro- 
cess state to be saved and control to be transferred to the 
beginning of the short-term scheduler routine at the dis- 
patcher entry point. Upon entry, the dispatcher ensures 
that just one processor at a time is active within the critical 
section of the dispatcher by attempting to lock a word 

•In Ihis article granularity is a measure ol the size ol independent operations that a 
process or a program can be Droken up into lor parallel processing In each case, the 
performance benelits gained by parallel processing must be weighed against the system 
overhead required to break up the process or the program That is. liner granularity requires 
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associated with that critical section. Once inside the critical 
section, the dispatcher scans the linked list of available 
processes using a special hardware linked-list search in- 
struction. The highest-priority process that is not blocked 
and is not currently running on another processor is 
selected for execution. The dispatcher's lock word is re- 
leased and the process is launched by setting the the CPU's 
current task control block pointer to point at the selected 
process. The context switch is completed by executing an 
IXIT instruction as described earlier. This results in the 
restoration of the state of this task and its continued execu- 
tion until it is either blocked or is preempted. 

If no tasks are found that are available for execution, the 
dispatcher's lock is released and the special instruction 
SLEP is executed. SLEP places the processor in a state where 
it is paused until the next interrupt or interprocessor mes- 
sage. In this way processors that have no work to do con- 
sume no bus bandwidth, yet are prepared to respond 
quickly when an event indicating the possible presence of 
a new runable task occurs. 

Performance 

The final test of the design of any multiple-processor 
system is in how much improvement in performance is 
provided by each additional processor. Fig. 3 shows the 
results of a number of benchmark runs which were made 
by running four copies of an identical benchmark on each 
of four processor configurations. The programs were 
selected to show the performance extremes that can be 
encountered in a multiple-processor system load. The pro- 
grams showing the least improvement were STRING 16K 
and STRING 80B. These programs make use of the proces- 
sor's block-move instructions, which are capable of moving 



data from one place in memory to another at the rate of 
9M bytes/s. Large and repeated block moves place a heavy 
load on the memory processor bus. 

The two-dimensional graphics benchmark is mostly l/O- 
bound on a single processor and adding additional proces- 
sors does not produce a very dramatic result. The other 
benchmarks, 3D GRAPHICS, INTEGER, PCAL, and FLOAT- 
ING, are respectively a three-dimensional graphics program 
with I/O, an integer matrix multiply program, a very heavily 
recursive program, and a floating-point matrix multiply 
program. All of these loads are significantly improved by 
having additional processors in the system. 

Fig. 4 shows the results of tests in which groups of 
non identical processes were run on systems containing a 
varying number of processors. The results from these runs 
are more uniformly clustered near the theoretical n-im- 
provement-for-n-processors asymptote. This indicates that 
a significant improvement is possible even for loads includ- 
ing bandwidth-intensive programs such as STRING 16K as 
long as they are included with programs containing more 
typical instruction mixes. 
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An I/O Subsystem for a 32-Bit Computer 
Operating System 

by Robert M. Lenk, Charles E. Mear, Jr., and Marcel E. Meier 



MEETING THE DIVERSE NEEDS for input/output 
processing for both the BASIC and HP-UX subsys- 
tems in the HP 9000 Series 500 Computers posed 
a significant challenge during the design of the operating 
system called SUN. The BASIC language system for the 
Model 520 Computer provides a rich I/O language with 
support for real-time device and instrument control. HP-UX 
is a multiuser system which relies very heavily on rapid 
access to disc storage for loading user programs, storing 
user data, and managing virtual memory. In addition, both 
systems provide users with a unified, device-independent 



I/O interface to all peripheral devices and mass storage 
files. SUN's I/O subsystem provides common code that 
fully supports the needs of both. 

The SUN I/O system consists of two primary software 
components — the file system and the device drivers. The 
device drivers provide a uniform high-performance inter- 
face for managing peripherals while the file system pro- 
vides file management, disc memory management, and de- 
vice management services to other components of the 
operating system as well as to user environments such as 
HP-UX and BASIC. In general, the structure of the I/O sub- 
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system (Fig. 1) mirrors the functionality of the hardware. 
File System 

The basic unit of disc storage managed by the file system 
is called a volume. Each volume has a slave process that 
performs all the I/O to the volume. The creation of a sepa- 
rate, transparent process allows physical I/O to be per- 
formed concurrently with other tasks and provides a 
mechanism whereby I/O requests can be scheduled in the 
most efficient manner possible. Volumes have self-con- 
tained data structures upon which files and directories are 
implemented. Directories, which map filenames into files, 
are managed solely by the file system while the interpreta- 
tion of the contents of files is left to higher-level software. 
Multiple Disc Formats. The file system supports file man- 
agement of three different disc formats: HP's Logical Inter- 
change Format (LIF), the disc format used by the HP 9825, 
HP 9835. and HP 9845 family of computers, and the Struc- 
tured Directory Format (SDF). The support for multiple 
disc formats was motivated by the desire to provide file 
interchange capability with other HP systems, to access 
discs initialized on earlier HP computers (backward com- 
patibility), and to provide additional capability not sup- 
ported by either the LIF or HP 9845 formats. The support 
for multiple disc formats does not introduce additional 
overhead to the file system. 

A distinct software module manages each of the three 
formats. A common interface hides the disc format differ- 
ences from other file system software and the BASIC sub- 
system. When a disc is first accessed, the file system iden- 
tifies the disc by the contents of block 0 on the disc and 
installs the correct software module to manage its structure. 
The file system returns an error if the caller attempts to 
use a feature not supported by the particular disc format, 
but otherwise no distinction between formats can be made 
by the application, Because of its extended capability. HP- 
UX supports only SDF as its root file system. However, 
HP-UX applications can access LIF discs through standard 
utility programs. 

SDF supports capabilities beyond those of (he other two 
disc formats. Among them are extensible files, hierarchical 
file naming, file links, extensible directories, mounted vol- 
umes, device files, remote file access support, and HP-UX 
file protection mechanisms. 

Each file on an SDF volume is described by a 128-byte 
file control block (FCB), similar to (he UNIX'" inode. The 

UNIX isaUS trademark ol Bell Laboratories 



Fig. 1. The SUN operating sys- 
tems HO subsystem 

FCB con(ains information about where the file resides on 
the disc, when it was last created, accessed, and modified, 
and how its use should be restricted. Disc space is allocated 
to the file in contiguous areas called extents (identified by 
the address of the first block of the disc area and its size). 
This form of representation enables large, high-speed trans- 
fers between the disc and the memory, supports large files 
efficiently, and allows the amount of disc space allocated 
to the file to change dynamically. 

To support the needs of both the BASIC and the HP-UX 
systems, a portion of the FCB is reserved for private use 
by the subsystem that created the file. HP-UX. for example, 
uses this private data area to implement device files and 
HP-UX-style file protection semantics. 
Caching for Improved Performance. The file system uses 
a pool of equal-size buffers (buffer cache) to improve disc 
access performance. When data is read from the disc, it is 
placed and kept in the buffer cache. When a subsequent 
request is made for the same data, it can be retrieved from 
the cache without requiring any physical I/O operation. 
Accessing data in the cache is more than an order of mag- 
nitude faster than obtaining the same data from the disc. 

The number of buffers in the cache is determined when 
the system is initialized. Eventually (he contents of one or 
more buffers has to be discarded to read new data from the 
disc (data not found in the cache). In this event, the cache 
buffer that has been least recently accessed is chosen. 

The cache is also used to improve performance in other 
ways. When sequential access to a file is detected, the file 
system prereads data from the file in anticipation of the 
next read request. The data is then kept in the cache until 
it is needed. The I/O required for the read is performed 
concurrently with the running of the application program. 
By prereading data, the file system overlaps CPU processing 
with I/O device time, thereby reducing the total time it 
takes to run an application. 

A large portion of the time needed to move data to and 
from (he disc is spent waiting for the disc to prepare for 
the transfer. The actual transfer of data takes much less 
time. The file system transfers as much data as possible on 
each disc read/write. When prereading data, several buffers 
of data are read from the disc with one transfer. The cache 
also allows a file's dirty buffers (buffers (hat must be written 
back to the disc because their contents have been modified) 
to be gathered together and written to the disc in a single 
transfer. 
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Virtual Memory Support. Since many HP-UX systems are 
configured with only one disc, the file system must handle 
file management and virtual memory support together on 
a single volume. Each disc format module has entry points 
that the virtual memory system uses to allocate and deallo- 
cate disc blocks. These same high-speed disc space manage- 
ment routines are used by the file system to allocate disc 
space for directories and files. Disc storage is fully shared 
between the file system and the virtual memory system. 
The physical I/O generated by the virtual memory system 
as a result of paging and segment swapping does not move 
through the cache, because the virtual memory system does 
its own caching through sophisticated page and segment 
replacement algorithms. This I/O is sent directly to a vol- 
ume's I/O process. The file system and virtual memory 
system together support the concept of a memory-mapped 
file. Files can be mapped onto a virtual segment and ac- 
cessed through a pointer. Once mapped, the virtual seg- 
ment contains an image of the file. Changes to the address 
space represent changes to the file and vice versa. This 
form of access is sometimes more convenient than standard 
file access routines and can, in certain applications, result 
in improved file access performance. 
Transparent Device I/O. Transparent device I/O for HP-UX 
is supported through device files, which contain informa- 
tion about the location of a device (possibly logical) in the 
system, and the manner in which the device and system 
must communicate. These special files are opened and ac- 
cessed in the same manner as other files. Their I/O, how- 
ever, is directed to the appropriate device. 

Drivers 

The underlying philosophy behind the driver architec- 
ture is that each piece of hardware is encapsulated by a 
separate module. A typical I/O operation involves three 
separate pieces of hardware: an I/O processor, an interface 
card, and a peripheral device. 1 Thus, the driver implemen- 
tation includes modules in three layers — I/O primitives, 
first-level drivers, and second-level drivers. This allows 
drivers to be mixed and matched lor appropriate tasks with- 
out duplicating functions. Thus, all peripherals, whether 
discs, tape drives, line printers, or voltmeters, can share 
the same HP-IB (IEEE 488) interface card first-level driver, 
while a single CS-80 protocol second-level driver can suf- 
fice both for HP-IB-based discs and the internal discs on 
the Series 500's integrated workstation, the Model 520 (see 
Fig. 2). Because of this modularity, the potential also exists 
to move any first-level driver to other machines where the 
same interface cards are present on different I/O channels, 
or to move any second-level driver to other machines where 
the same peripherals use different interface cards. 

Each of the three layers invokes the one below it through 
a procedure call. This keeps the overhead of the modulari- 
zation to a minimum. However, in special cases where 
even this overhead is considered excessive, an individual 
driver module crosses these conceptual layers to optimize 
performance. A primary example of such an optimization 
is a special driver to do fast reads and writes of CS-80 discs 
on the HP-IB interface. 

The modular driver organization allows software to be 
configured to match precisely the hardware on which it 



runs. A minimal software system contains only the I/O 
primitives and the drivers necessary for a minimal 
hardware configuration without wasting kernel code space 
on unnecessary modules. As more hardware is added, the 
corresponding drivers are added to the software. All global 
system tables of drivers and devices are built dynamically 
by the modules that are present at system boot, rather than 
being compiled into a central part of the code or requiring 
a complicated system generation activity. Hence, the addi- 
tion of drivers does not require any recompilation or relink- 
ing of the system; it is accomplished by simply merging 
the driver code into the system boot area in HP-UX and 
rebooting, or by executing the LOAD BIN command in BASIC. 
The same ability to configure modules into the system is 
used by the file system for the modules that manage differ- 
ent disc formats, and by other subsystems outside of I/O. 
I/O Primitives. The primary purpose of the I/O primitives 
module is to encapsulate the interface to the I/O processor 
and the services it provides. These services include direct 
memory access (DMA) transfers across the backplane, pass- 
ing interrupts to the CPU, and running channel programs 
(lists of I/O operations which are run by the I/O processor 
without CPU intervention). These services are presented 
to the drivers as routines that are independent of the nature 
of the I/O processor, such as setting up a DMA transfer or 
waiting for the interrupt at its completion. A few of these 
routines that are simple but frequently executed are im- 
plemented with special compiler support by in-line expan- 
sion in the calling driver's code. 

There are other tasks which, though not directly related 
to the I/O processor, are common to several drivers, and 
thus are also included at the primitives layer. For example, 
the primitives module examines all I/O slots at system in- 
itialization to determine which interfaces are present. This 
is an essential part of the self-configuration process, be- 
cause it allows each first-level driver to select which in- 
terface cards are appropriate for it to address without 
any knowledge of the behavior of other cards that may 
be present. 

The primitives also provide for resource allocation 
among drivers to prevent multiple requests from interfering 
with one another. This is generally handled by providing 
mutual exclusion to each I/O slot, but it also involves the 
length of request. For shorter requests, interfaces such as 
terminal multiplexers allow multiple outstanding requests 
with certain restrictions, which are enforced by the primi- 
tives. For longer requests, each I/O processor has 
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bandwidth limitations, and in rare instances it is possible 
for a high-speed device to lock out a synchronous device 
on a separate slot. The primitives provide mutual exclusion 
between such incompatible devices on the same I/O proces- 
sor. 

HP-CIO. The HP 9000 Series 500 Computers are the first 
HP products to support HP's new family of interface cards, 
known as HP Channel I/O (HP-CIO). Each card in this family 
shares several levels of protocol, some of which communi- 
cate fairly complex tasks between the host computer and 
a microprocessor on the card. The card's microprocessor 
can perform such tasks as searching input streams for a 
termination character, or editing lines of text input from a 
terminal. Much of this protocol is encapsulated at the 
primitives level, allowing not only a sharing of code among 
drivers, but also efficient implementation of the protocol 
by matching it carefully to the I/O processor's functionality. 

The I/O primitives level provides a useful layer to insu- 
late the drivers from the I/O processor. Hence, all the inter- 
face card and peripheral drivers can be written in MODCAL 
(HP's internal Pascal-like systems programming language) 
rather than being forced to use assembly language. This 
encapsulation of the assembly language in the I/O primi- 
tives reduces the time required to design, code, test, and 
maintain the driver compared to programming in assembly 
language. The reliablity of the drivers is greatly improved, 
because it is easier to understand the code and its function 
when the code is in a high-level language. 
First-Level and Second-Level Drivers. The first-level and 
second-level drivers are designed to hide the anomalies of 
the peripherals and interface cards while providing all the 
functions that each device provides (e.g., full access to the 
instrumentation features of the HP-IB interface). 
Nonspecific device features are relegated to higher levels 
of the I/O hierarchy to prevent duplication of functions 
that would increase the overall size of the I/O subsystem, 
reduce performance, or possibly present inconsistent be- 
havior for different drivers. In addition to encapsulating 
the specific peripheral or interface card characteristics to 
provide access to a generic device, the driver design pro- 
vides access to rather dissimilar devices (e.g., discs and 
HP-IB interface cards) with the same parameters for either 
the first- or second-level driver procedures. This uniformity 
provides the first step in supplying the user with a totally 
device-independent I/O interface. 

The SUN operating system drivers also provide ex- 
tremely resilient recovery from error conditions. They have 
been through a thorough set of tests to ensure that the 
drivers never leave the device they control or leave the 
system in a bad state (requiring a power cycling of the 
computer or device) as a result of any possible error condi- 
tion. Extra effort was taken to provide a broad resolution 
of error conditions reported to the system rather than com- 
bining many different errors into generic error values. The 
drivers also provide numerous different soft-error reports 
to inform the user of nonerror related data such as the 
occurrence of an automatic data record sparing (replace- 
ment of a bad record with a good record) on a mass storage 
medium or a case where the system had to retry an access 
to a data record to obtain it without an error. This additional 
resolution and the soft-error concept provide the user with 



a more informed view of the operation of the system instead 
of requiring a guess as to what is going wrong. 

HP's earlier desktop computers have always provided 
access to the hardware registers on the I/O cards to provide 
customers with access to features not provided by the I/O 
language of their system. However, the new-generation HP- 
CIO cards are far more complex to program and in addition, 
do not have conventional registers. Thus, the SUN drivers 
provide a synthesized set of registers, called pseudoregis- 
ters. This provides the user with the same model as on the 
HP 9845 Computer for accessing features of an I/O card not 
normally provided by the system, but done in cooperation 
with the driver. Thus, the driver has the opportunity to 
provide additional functions in an isolated manner. This 
allows the same pseudoregisters to be used for different 
implementations of the same type of interface card, which 
increases the portability of user applications. 

The SUN drivers support the broad set of peripherals 
produced by Hewlett-Packard. Instead of initially supply- 
ing a core set and then adding less-essential drivers at a 
later time, SUN provides support for all peripherals that 
make reasonable sense for the HP 9000 marketplace. One 
additional driver that is somewhat unusual is the mem- 
ory driver. This driver uses the main memory of the running 
system to simulate a disc drive. The code required to pro- 
vide this driver is a great deal simpler than if this function 
were provided at a higher level. The result is that a user 
can develop an application that accesses a disc file and 
then decide to store the data in main memory to gain the 
performance advantage of not having to spend the time to 
access a disc drive. The change is trivial using the memory 
driver; simply revise the reference to the specific mass 
storage device to be the memory driver rather than the 
original disc drive. 
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Viewpoints 



Coping with Prior Invention 

by Donald L. Hammond 



THIS MONTH. HEWLETT-PACKARD is introducing a new 
printer, the Thinkjet (HP 2225), which offers what we be- 
lieve is an unprecedented combination of features: 150 
character-per-second printing speed, archival print on ordinary 
paper, small size, quiel operation, and low cost — both initial cost 
and total cost of ownership. Power requirements are so low that 
one model is available with a battery pack that provides more 
than three hours of printing, or about 200 pages. These advantages 
have been made possible by a new ink jet printing technology, 
which we have called thermal ink jet, or more picturesquely, 
"Thinkjet." to differentiate it clearly from the more common kind 
of thermal printing, which requires special paper. 

We think the story of this technology development is an interest- 
ing example of what can happen in today's fast-moving technolog- 
ical environment. In our HP Laboratories at Palo Alto, in the fall 
of 1978, John Vaught was looking for a new printing method that 
would have the advantage of inherent simplicity compared with 
the rather complex electrophotographic process used in the HP 
2680A Laser Printer, for which John had designed the optical 
scanning package. 

He started with the idea of turning ink into vapor by high-speed 
electrolysis and heating, using pressure to eject drops. When this 
was found to work but with serious failure rates, he conceived 
the idea of using a small resistor, which when heated for a few 
microseconds by a current pulse, created bubbles, thereby ejecting 
drops of ink from a nozzle. This was first demonstrated in March 
1979. 

We proceeded to develop this idea, amidst some skepticism that 
the necessary performance and reliability could ever be achieved. 
The Thinkjet printer is testimony that these concerns were dis- 
persed by extensive development work in several HP organizations 
on the process and structure. One of the key concepts, originated 
at HP's Corvallis Division, was a lotally disposable ink jet head 



with a self-contained ink supply. 

It is not uncommon, when an important problem such as quality 
printing receives Ihe attention of many people, that independent 
conception occurs in isolated research centers. Such was the case 
wilh Thinkjet. In September 1981 we learned of the existence of 
the same concept under development at Canon. Inc., in Japan. 
Ichiro Endo had conceived the idea independently, with an earlier 
invention date. Canon referred to the technology as "Bubblejet." 

Since we in HP were convinced that this new technology had 
great promise. Ihe arrival of a new player in this arena caused 
some concern as to our respective technical positions. There were 
a number of options but the most attractive for HP was to work 
with Canon. Excellent ties between the two companies had already 
been established as a result of our acquisition from them of tech- 
nology for electrophotographic printers several years earlier. 

Hewlett-Packard and Canon have agreed to cooperate in the 
technology development. Because this process started in 1983, the 
sharing of technical data has had no major impact on our first 
product release, but we can feel the positive effect that it is having 
on our continuing developments. Canon has reflected to us similar 
feelings. Working wilh a group that represents a comJjination of 
cooperation and competition has provided a valuable perspective, 
especially increased objectivity, for the technical and management 
teams of both companies. 

This experience has reinforced the principle that technology 
alone can rarely make a significant contribution in this complex, 
fasl-moving world. There are equally valuable elements, some- 
times involving the resolution of relalionships in the spirit of 
international competition and cooperation, that can have dramatic 
effects on our ability to bring that technology to Ihe market. 

We will be reporting in a future issue on more details of these 
developments, including the Thinkjet printer. 
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